Subject: Overlap sending with Record-Route is broken ( was [SIP] Overlap Sending)

From: "Keith Robinson" <[email-masked]>
Date: Tue, 9 Jan 2001 10:00:54 +0000

Hi,

I  take your point about requiring a proxy to route [email-masked] the same
way as [email-masked] but I believe this to be entirely within the routing data
set up
by the administration. Allowing clients to choose there own path through the
network
to get to their desired destination using various digit sequences seems like the
classic way of
exposing networks to fraudulent use (billing avoidance, bypassing security,
etc). However,
I think this is a seperate issue.

I am still concerned about the Route header overwriting the R-URI and therefore
destroying the subsequent
digits when subsequent messages are routed using the Route header mechanism. I
am not sure that
putting the subsequent digits in the TO header helps because I believe the TO
URL is supposed to
be invariant during the lifetime of the call leg. Modifying the TO URL after the
initial INVITE I think will cause
problems for proxies  that are using the TO URL to match subsequent requests to
call legs in progress.

Without introducing a new header to carry the digit string, then I think the
only other way to make
overlap sending work is for the 484 to clear down the call leg as other 4XX
responses do and subsequent
INVITES with the original digits + additional digits to be a new INVITE (with a
new Call-Id). The initial INVITE
will not be routed using Route headers, so the digit string in the R-URI will
not be lost.  There still could be
a problem if the client has built a Route header (learnt out-of-band) and puts
this in the initial INVITE; the
same problem may occur.

Without clarification of this matter in the bis draft then I don't think overlap
sending is going to
be interoperable.

Regards,

K. Robinson.

Christer Holmberg <[email-masked]> on 09/01/2001 07:36:51

                                                              

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

 Subject: Re: [SIP] Overlap Sending                           

Hi,

>>"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..."
>
>One way of ensuring that subsequent requests always traverse a given SIP
>node is for that node to Record-Route or supply a Contact ; it is likely
>that proxies and UAS at PSTN interworking points will require to stay in
>the signalling path during call setup so will do so.  Now, suppose one
>such node receives an initial INVITE with a R-URI of sip:[email-masked]
>and creates a Contact header thus:
>
> Contact: sip:[email-masked];maddr=sipgw.com

Let's assume that the first proxy (P1) receives the R-URI
sip:[email-masked] and forwards it
to P2, which insert itself in the route and returns 484. The client then
sends [email-masked], which goes via P1 to P2. P2 then forwards it
somewhere else etc., until it reaches the final UAS.

However, if the client would have sent [email-masked] in the initial
INVITE, P1 would maybe have forwarded it to P3 instead of P2, which
means that the subsequent [email-masked] will take another route. This
may not be a problem, but again - you MAY want to send a specific number
via a specific proxy (for load balance/billing/monitoring/whatever
reason) - no matter if how the number is divided between INVITE
messages.

Again, this could be solved if you are able to configure the proxies.
And, if you don't own the proxies you could send some kind of digit map
header, telling the proxy to forward any matching number to the same
place (e.g. P2).

Then:

INVITE [email-masked]
Forward-digit-map: 65xxxx

...would be treated, and forwarded by proxies, exactly like...

INVITE [email-masked]
Forward-digit-map: 65xxxx

A possible problem with this approach, though, is that the UAC would
tell the proxy what to do, but that is possible using the SIP Caller
Prefs anyway, so...

Just an idea...

>This is then returned in the 484 response so that the sending UA may
>build a Route header from it. Here is my first concern; will the sending
>UA treat the subsequent INVITE as a subsequent INVITE or as a new INVITE
>on a new Call-Id ? I ask because the 484 response is non-200 final
>response which implies that that call attempt has failed; obviously in
>this case it hasn't failed (not yet, anyway) its just been partially set
>up. Does this lead to special case handling for a particular 4XX response
>? In fact, the 484 is almost like an informational response.
>Would it be better to send an informational response (say 183) and the
>spec updated to allow subsequent INVITEs to be sent before the final ACK
>(a point raised by J. Rosenberg earlier on the list, but in a different
>context - to convey updated SDP information).

Allowing subsequent INVITEs before a final answer would also solve some
ISUP transparency issues. However, allowing it would probably - again -
produce lots of problematic cases (again, especially in a SIP/PSTN GW
scenario) and what-ifs, so IF it is to be allowed it should be very
cleary defined HOW and in WHAT FOR.

>Assuming the above is resolved one way or another, then a SIP node
>preceding sipgw.com is going to receive a subsequent INVITE for this call
>(containing additional digits 321)  that will look something like:
>
>INVITE sip:[email-masked]
>Route: sip:[email-masked];maddr=sipgw.com
>
>As a Route header is present, this will be used to route the INVITE so
>therefore sipgw.com will receive an INVITE with the following Request
>Line:
>
>INVITE sip:[email-masked];maddr=sipgw.com
>
>And here is a more worrying problem, the subsequent digits have been lost.
>The situation would be no better if the subsequent INVITE contained original
>digits plus subsequent digits; they would still be lost.
>
>The problem stems from the fact that the R-URI is supposed to be invariant at
>each node during the lifetime of the call leg, yet to do overlap sending it is
being
>used to convey new information so therefore does not remain invariant and other
parts of
>the protocol which assume it is invariant e.g., routing using the Route header
>break.
>Using a TEL URL does not help either; the digits would still be lost >after the
popping of the Route entry >into the R-URI.

Personally I don't see ANY case where TEL URL would help with ANYTHING
in a SIP network... :) It will just produce extra DNS lookup traffic.

>It would be easier to implement overlap sending if a seperate header
>could be used to convey the dialled digits, so an original INVITE may >look
something like:
>
>INVITE sip:[email-masked]
>Current-Dial-String: 01623
>
>The subsequent INVITES would then look something like:
>
>INVITE sip:[email-masked];maddr=sipgw.com
>Current-Dial-String: 01623654398

Won't the To header show the current dial string, because it will not be
changed by proxies?

i.e.

INVITE sip:[email-masked];maddr=sipgw.com
To: [email-masked]

...and the subsequent request...

INVITE sip:[email-masked];maddr=sipgw.com
To: [email-masked]

>This ties in with your point of implementing a digit map header.
>
>Regards,
>
>K. Robinson.

Regards,

Christer Holmberg
Ericsson Finland

> Christer Holmberg <[email-masked]> on 08/01/2001 3:40:47
>
>
>
>
>
>
>
>  To:      [email-masked]
>
>  cc:      Keith Robinson/MAIN/MC1@MCMAIN, Steve Levy
>           <[email-masked]>
>
>
>
>  Subject: Re: [SIP] Overlap Sending
>
>
> Hi,
>
> >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] ?
>
> 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)...
>
> >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.
>
> 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
>
> > Regards,
> >
> > K. Robinson
> >
> > Christer Holmberg <[email-masked]> on 08/01/2001 10:43:36
> >
> >
> >
> >
> >
> >
> >
>
> Keith Robinson wrote:
> >
> > 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