Subject: Re: [SIP] Overlap Sending

From: "Keith Robinson" <[email-masked]>
Date: Mon, 8 Jan 2001 11:59:15 +0000

If a proxy, not serving uas.com, receives an INVITE with a R-URI of [email-masked],
why
would it route it differently (Route headers not withstanding) from an INVITE
with a R-URI of [email-masked] ?
Surely, if the proxy does not serve the domain identified in the R-URI it cannot
make any
routing decisions based on the user part of the R-URI.

If, on the other hand, the proxy does serve uas.com, then it will be involved in
routing the call using the dialled
digit string and I would expect it to know such things as minimum digits to
translation and perhaps even
maximum number of digits to follow. Also, because the proxy is doing digit based
routing it must be subject to the
requirements of overlap sending so I would expect it to be stateful, at least
until call setup is complete, in which
case remembering previous call information would be reasonable. In fact, such a
proxy appears much like the
interworking UAs I referred to previously and to which my question applies.

Regards,

K. Robinson

Christer Holmberg <[email-masked]> on 08/01/2001 10:43:36

                                                              

 To:      [email-masked]                             
                                                              
 cc:      Keith Robinson/MAIN/MC1@MCMAIN, Steve Levy          
          <[email-masked]>                                  

 Subject: Re: [SIP] Overlap Sending                           

Hi,

I think sending re-INVITES containing only subsequent digits will create
some problems. It's not enough that the UAS remembers the previous
INVITEs for the specific Call-ID, you may also have intermediate
redirect- and/or proxy servers that make their redirect/forwarding
decissions based on the destination number, and then they would also
have to remember the previous INVITEs, and they would possible also have
to be able to know if, and in some cases, how many digits will follow
(e.g. [email-masked] may be routed to a complete destination than
[email-masked], etc.) Maybe we should implement some kind of digit-map
header, or something... :)

Regards,

Christer Holmberg
Ericsson Finland

Keith Robinson wrote:
>
> Yes, this is the type of case I have in mind. The question I have is what are
> the subsequent INVITES; are they
>
> a) New INVITES, on a new Call-Id containing the original digits (from original
> INVITE) + subsequent digits ?
>
> or
>
> b) re-INVITES containing only subsequent digits ?
>
> or
>
> c) re-INVITES containing original digits + subsequent digits ?
>
> The sending UAs I referred to in my previous note are those that sit in
PSTN/SIP
> gateways,
> not necessarily an originating UA sitting on someones desktop.
>
> So, the question applies as much to these interworking UAs for constructing
> the subsequent INVITEs as well as to receiving UAs for interpreting them.
>
> Regards,
>
> K. Robinson.
>
> Steve Levy <[email-masked]> on 05/01/2001 22:32:00
>
>
>
>
>
>
>
>  To:      Keith Robinson/MAIN/MC1@MCMAIN,
>           [email-masked]
>
>  cc:
>
>
>
>  Subject: Re: [SIP] Overlap Sending
>
>
> Hi Keith,
>
> I was wondering if in considering overlap sending issues and SIP if you were
> considering the case of overlap sending across multiple networks with variable
> length digits.
>
> In this case, in order to avoid post dial delay, the digits need to be passed
> through the networks to the final destiantion network prior to end of dial
> (since the destination network is the only network that knows how many digits
> are required). So in effect there may be additional digits sent after an
INVITE
> has been received and sent downstream to the callee.
>
> Thanks,
> Steve
>
> At 03:50 PM 1/5/01 +0000, Keith Robinson wrote:
> >
> >
> >I have the following query regarding overlap sending as defined in
> >rfc2543bis-02:
> >
> >Section 4.2.1 states the following:
> >
> >"...the UAS compares the Request-URI with Request-URI of the previous INVITE
> >request
> >for the same Call-Id. If the Request-URI  contains additional digits in the
> >'user' part, the UAS
> >treats the INVITE as adding additional digits to the original dialed string."
> >
> >This appears to imply that the subsequent INVITE contains the original
dialled
> >string plus the
> >additional digits; if this is the case, then there is no need for the UAS to
> >remember the
> >previous string, and therefore no need to keep any state regarding the
previous
> >attempt.
> >The subsequent INVITE can really be a new INVITE., i.e. a new Call-Id.
> >
> >If, on the other hand, the sending UA only sends additional digits, then the
> >original digits
> >will have to be remembered by the UAS, and the INVITE matched up with this
> >state
> >so
> >this INVITE must be on the same Call-Id.
> >
> >This latter case is similar to the way existing telephony protocols transmit
> >addtional digits
> >when doing overlap sending.
> >
> >So, upon receiving a response of 484 Address Incomplete, does the sending UA
> >send
> >original digits plus aditional digits on a new Call-Id or additional digits
> >only
> >on the same
> >Call-Id with an incremented Cseq.
> >
> >Regards,
> >
> >K. Robinson.
> >
> >
> >
> >
> >_______________________________________________
> >SIP mailing list
> >[email-masked]
> >http://lists.bell-labs.com/mailman/listinfo/sip
>
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
>
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 08 Jan 2001 15:40:47 +0200

Hi,

>why would it route it differently (Route headers not withstanding) from an INVITE

I don't know. I haven't seen a proxy that would route depending on the
user, but it COULD happend. Let's assume , for example, that you do a
SRV DNS lookup, and get a list of servers. Then you MAY choose a
different server, for load balance purpose e.g., depending on the user
name. Just an example...

And, what happen if you use a TEL-URL, where you have to route depending
on the user name (=telephone number). I guess using a ENUM DNS lookup
COULD route it to the same host, but then I guess you would have to
configure your DNS to for all the possible combinations (4.e164.arpa,
44.e164.arpa and 441.e164.arpa)...

>make any routing decisions based on the user part of the R-URI. 
>routing the call using the dialled digit string and I would expect it to know such things as minimum digits to
>translation and perhaps even maximum number of digits to follow. Also, because the proxy is doing digit based
>routing it must be subject to the requirements of overlap sending so I would expect it to be stateful, at >least until call setup is complete, in which case remembering previous call information would be reasonable. >In fact, such a proxy appears much like the interworking UAs I referred to previously and to which my question >applies.

That was my point - that you also have to have support for this in your
proxies, and not only in your client.

I think the issue is that there are lots of what-ifs involved in this,
and it should be specified how the specific cases are handled -
especially by proxies and redirect servers.

Regards,

Christer Holmberg
Ericsson Finland