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: joel.ger...@corp.eastlink.ca T: 519.786.1241
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu]
> Sent: July-16-13 11:39 AM
> To: sip-implementors@lists.cs.columbia.edu
> 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"<br...@broadsoft.com>;
>> Date: Tue, Jul 16, 2013 07:56 PM
>> To: "SIP Learner"<rfc3...@foxmail.com>;
>> "sip-implementors"<sip-implementors@lists.cs.columbia.edu>;
>>
>> 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
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
