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
