On 7/16/13 3:33 PM, Joel Gerber wrote:
> Sorry; dialog being modified wasn't the most accurate terminology. The way I
> understand the workings in the Genband environment, the subsequent (and
> preceeding) digits are sent in an INFO message either during the provisional
> stage of dialog setup or after the dialog is fully established. I think it's
> after it is fully established, but I don't know this for 100%. And, yes, I've
> only seen this used in an ISUP to SIP gateway environment.
Well sure, you could do the INFO in an early dialog or a final dialog.
I presume you would do it in an early dialog, because you don't want to
establish the final dialog until the callee has answered.
> E.164 is an ITU-T specification that defines how digits are to be represented
> when being signaled between switching devices. In basic, the format is a
> string always preceeded with a `+`, then the country code, and then the rest
> of the digits as defined by the local dialing plan. IE: +15197861241 for my
> phone number. This is a standard that is pretty much always followed for
> international calls, and is becoming common for calls between carriers even
> if they are in the same calling area when they are peering with SIP. With
> E.164, you are guaranteed(-ish) a globally unique number, which can make call
> routing simpler, especially when you want to be able to make a quick
> determination on the routing path to take without necessarily having to
> translate on all of the digits.
I know what E.164 is. But that doesn't help much. The problem is that a
phone is trying to gather enough digits to construct a URI that
identifies the destination. In the sort of system you are talking about
that destination may actually represent a collection of numbers with a
common prefix, but you need it to be a destination that can terminate
the call for all numbers in that collection.
So how does the caller know how many digits to gather?
If it is a NANP-aware phone and calling a NANP number, then it knows the
structure of the NANP and so can gather the right number of digits.
But if the caller dials the international dialing prefix, and a country
code, and some digits, will the phone know the structure of numbers for
that country, so it will know how many digits to gather? I have never
seen a unified description for all countries that would support that.
An alternative would be to simply gather the country code, and then send
an INVITE, and hope that something will answer that can use the INFO
scheme. But I don't think you will find that.
Thanks,
Paul
> Joel Gerber
> Network Specialist
> Network Operations
> Eastlink
> E: [email protected] T: 519.786.1241
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:[email protected]]
> Sent: July-16-13 3:27 PM
> To: Joel Gerber
> Cc: [email protected]
> Subject: Re: [Sip-implementors] Overlap signaling in a native SIP network
>
> On 7/16/13 1:41 PM, Joel Gerber wrote:
>> I believe it actually establishes the dialog with the partial digits. Then
>> the dialog is modified with the new digits as they are received. I haven't
>> tested this in a lab, so I can't be 100% sure, but that is what I've been
>> led to believe.
>
> What do you mean "dialog is modified"???
>
> I see how this can work if the initial sip signaling reaches a gateway to a
> network that supports digit by digit dialing.
>
> But I don't see how this would work in an all-sip network.
>
>> As to your question about how many digits must be sent at minimum, depending
>> on the calling plan... I'm not sure, but I believe most carriers would
>> negotiate using a E.164 dialing plan which will give you enough information
>> to properly start call routing even with partial digits. That's what I do
>> with most (all but one) of my carrier interconnects.
>
> And what is an E.164 dial plan? Does it have a plan for every country code?
>
> AFAIK most systems handle this via a timeout on the dialing and then do en
> bloc.
>
> Thanks,
> Paul
>
>> Joel Gerber
>> Network Specialist
>> Network Operations
>> Eastlink
>> E: [email protected] T: 519.786.1241
>>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[email protected]]
>> Sent: July-16-13 11:39 AM
>> To: [email protected]
>> Subject: Re: [Sip-implementors] Overlap signaling in a native SIP
>> network
>>
>> The problem with the INFO method is that you first must establish a dialog
>> with *something*, and you need a URI do do that. And once you have
>> established that dialog, all the digits you send with INFO are going to it.
>>
>> So this really only works with certain topologies, and with the calling
>> device having policies about how many digits it needs to construct that
>> initial URI.
>>
>> So, suppose you have built a phone that is deployed in the US. And then the
>> user of the phone calls an international number - say a room in a hotel in
>> Germany.
>>
>> Does your phone have a dial plan for Germany? How many digits should it
>> collect before sending the INVITE? Based on those digits, what server (if
>> any) will you land on?
>>
>> Thanks,
>> Paul
>>
>> On 7/16/13 10:08 AM, SIP Learner wrote:
>>> Thanks to all!
>>>
>>>
>>> I found one internet draft that propose to use the INFO method to convey
>>> subsequent dialed numbers:
>>>
>>>
>>> http://tools.ietf.org/id/draft-zhang-sipping-overlap-01.txt
>>>
>>>
>>> It claimed to resolve the issues related to the INVITE/484/ACK approach in
>>> RFC3578, but this draft seems to be deceased only after one revision, don't
>>> know what's wrong with it!
>>>
>>>
>>>
>>>
>>> ------------------ Original ------------------
>>> From: "Brett Tate"<[email protected]>;
>>> Date: Tue, Jul 16, 2013 07:56 PM
>>> To: "SIP Learner"<[email protected]>;
>>> "sip-implementors"<[email protected]>;
>>>
>>> Subject: RE: [Sip-implementors] Overlap signaling in a native SIP
>>> network
>>>
>>>
>>>
>>>> In my opinion, if only a SIP network is involved and no gateways are
>>>> used, overlap signalling (e.g., the caller sends dialed digits to an
>>>> outbound proxy in consecutive separate INVITEs for the outbound
>>>> proxy to collect enough information and route the requests) is
>>>> meaningless, because there are no physical connections to be
>>>> established, am I right?
>>>
>>> It isn't meaningless; it wastes network resources and the devices would
>>> need to agree upon what should occur (i.e. how the digits are collected, et
>>> cetera).
>>>
>>> Even though draft-ietf-bliss-shared-appearances provides a PUBLISH
>>> mechanism for seizing an appearance, some vendors might also allow an
>>> INVITE/484/ACK exchange to temporarily keep an appearance seized.
>>> _______________________________________________
>>> Sip-implementors mailing list
>>> [email protected]
>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>
>>
>> _______________________________________________
>> Sip-implementors mailing list
>> [email protected]
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
