Subject: Re: [SIP] Overlap Sending

From: "Keith Robinson" <[email-masked]>
Date: Wed, 10 Jan 2001 10:17:36 +0000

If we say that the 484 clears down the call attempt and therefore associated
state in the preceding
SIP nodes then I have no problem with generating a new initial INVITE with a new
TO header; this
seems consistent with the RFC. Note that the paragraph in section 4.2.1 starting
"A UAS acting as a gateway.."
implies that the UAS that generated the 484 does not kill associated state with
this call attempt.

So, the problem I have with using the same Call-Id though  is
that it is unclear from the RFC what a UAS will make of the received request.
Referring to section 11.5
we get to case 3, where a request has been received with a Call-Id that matches
a current; however
case 3 only explains the meaning of the request if the To and From fields match
stored values at this point, -
"the request is a new transaction for an existing leg", it does not explain what
it means if either the From or To
fields are differ. Is it an update to either field ? Is it a request for a new
leg ? Is it erroneous. I have raised this
as a seperate question on the list as it is probably a more general problem.

I think it is therefore safest for the 484 to kill that call attempt and
associated state completely, including
within the terminating UAS that generated it. INVITES carrying the subsequent
digits (plus original digits)
in the TO field will  then be treated as brand new call attempts with no
ambiguity.

I am not advocating that this is the best solution, just the safest without
significant change to the RFC.

As I said previously, I believe a better solution would be to able to send
re-INVITES after an infomational
response, but before the final ACK. Of course, this would mean the TO field has
to remain consistent for all
these re-INVITES so could not be used to carry the subsequent digits.........

Advive on this matter from the SIP authors would be gratefully appreciated.

Regards,

K. Robinson.

Christer Holmberg <[email-masked]> on 09/01/2001 10:50:06

                                                              

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

 Subject: Re: [SIP] Overlap Sending                           

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.

Well, it's related :)

>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.

Well, this depends a little on how you define a call leg, I guess...
Since you got a 4xx response to your first INVITE, you didn't manage to
set up a call leg, so then you try to set up a "new" call leg - with a
new R-URI and To header...

INVITE [email-masked]
To: [email-masked]

<---- 484 -----

INVITE [email-masked]
To: [email-masked]

>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.

Since the proxy sent back 484, I wouldn't consider the call leg to be in
progress anymore (after the proxy receive the ACK, that is).

And, the proxy will probably have to do the routing based on the To
header, since the R-URI will probably (unless we use an outbound proxy)
be the address of the proxy itself, so if the To header isn't changed
the proxy will try to route [email-masked] every time, even if more
digits have provided by the client. And, if the proxy is supposed to
"combine" the Current-Dial-String header value with the To header, to be
able to route, I think that the client could put the new value in the To
header from the beginning. Because, if the proxy doesn't support the
Current-Dial-String it wouldn't be able to do anything, since both the
R-URI and To header could be the same in the subsequent INVITEs. If you
have a updated To header, and the proxy doesn't support the digitmap, it
would at least be able to route the new To header - even if the message
may take a "wrong" route.

>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).

I agree, but I don't think it requires a new Call-Id. Then we could
still define a digitmap header to make sure  (if it is supported by the
proxy) that the proxy will always route the message correctly, no matter
how many INVITEs you need to provide all digits.

>The initial INVITE will not be routed using Route headers, so the digit string
in the R-URI will
>not be lost.

Proxies may change the R-URI...

>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.

This will not be a problem if all servers in the path support the
digitmap... :)

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

I agree.

Personally I think (no, this is NOT a proposal to re-write SIP :) the
best way would be to have some kind of "multi-message" setup, and that
would also solve a number of other issues (i.e. ISUP transparency).

Regards,

Christer Holmberg
Ericsson Finland

Keith Robinson wrote:
>
> Let's consider the following point:
>
> "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
>
> 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).
>
> 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.
>
> 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
>
> This ties in with your point of implementing a digit map header.
>
> Regards,
>
> K. Robinson.
>
> Christer Holmberg <[email-masked]> on 08/01/2001 13: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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Jan 2001 13:48:40 +0200

Hi,

>state in the preceding SIP nodes then I have no problem with generating a new initial INVITE with a new
>TO header; this seems consistent with the RFC. Note that the paragraph in section 4.2.1 starting
>"A UAS acting as a gateway.." implies that the UAS that generated the 484 does not kill associated state with
>this call attempt.
> 

One idea would be to write that an UAS that sends a 484 response and
KNOWS it may receive a new INVITE with more digits (a gateway, for
example) MUST accept the same Call-ID (the To header is different,
though).

>Referring to section 11.5 we get to case 3, where a request has been received with a Call-Id that matches
>a current; however case 3 only explains the meaning of the request if the To and From fields match
>stored values at this point, - "the request is a new transaction for an existing leg", it does not explain >what it means if either the From or To fields are differ.

My understanding that when we have sent the 484 we don't have an
existing leg anymore. The UAS does have an ongoing transaction, waiting
for the ACK, but since we will send a new To header in the next INVITE
we will not mess with that transaction even if the Call-ID is the same.

>Is it an update to either field ?

I think that since multiple headers are used to define a call-leg, we
have a different call-leg as soon as one of them change, even if the
other headers (including the Call-ID) remains the same.

>Is it a request for a new leg ? Is it erroneous. I have raised this
>associated state completely, including within the terminating UAS that generated it. INVITES carrying the >subsequent digits (plus original digits) in the TO field will  then be treated as brand new call attempts with >no ambiguity.
> 

I agree. It is the safest, but not the fastest, since the gateway will
delete any possible information it could have used for the subsequent
INVITE.
 
>re-INVITES after an infomational response, but before the final ACK. Of course, this would mean the TO field >has to remain consistent for all these re-INVITES so could not be used to carry the subsequent digits.........

I agree. In that case I guess we would need a separate header, or a new
To header parameter, to transport the subsequent digits.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Doug Harbert <[email-masked]>
Date: Wed, 10 Jan 2001 19:52:53 -0700

Christer:

> example) MUST accept the same Call-ID (the To header is different,

    What if the caller cannot supply any more digits? When will the UAS be able to discard the saved call state?

> delete any possible information it could have used for the subsequent

    I think that assuming the 484 clears down the call attempt is the best solution. The transaction is complete when the UAS receives the ACK to this final response. The UAC that knows how to gather additional digits knows that the
call hasn't actually failed and can then issue a new INVITE with the additional digits. A UAC that doesn't know how to gather additional digits assumes that the call has failed. This is not much different from behavior on receiving 401
response. The UAC gathers more information (username and password) and issues a new INVITE to complete the call.

Doug Harbert

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jan 2001 11:14:03 +0200

Hi,

>>>"A UAS acting as a gateway.." implies that the UAS that generated the 484 does not kill associated state >>>with this call attempt.
>>>

I guess one easy way would be to use a timer (we do that in the PSTN
network too, so...).

>>>stored values at this point, - "the request is a new transaction for an existing leg", it does not explain >>>what it means if either the From or To fields are differ.
>>
>>>associated state completely, including within the terminating UAS that generated it. INVITES carrying the >>>subsequent digits (plus original digits) in the TO field will  then be treated as brand new call attempts >>>with no ambiguity.
>>>
>I think that assuming the 484 clears down the call attempt is the best solution. The transaction is complete >when the UAS receives the ACK to this final response. The UAC that knows how to gather additional digits knows >that the call hasn't actually failed and can then issue a new INVITE with the additional digits. A UAC that >doesn't know how to gather additional digits assumes that the call has failed. This is not much different from >behavior on receiving 401 response. The UAC gathers more information (username and password) and issues a new >INVITE to complete the call.

One problem with this approach, though, is that you must implement
buffering of digits. The PSTN side can provide you the digits very fast,
and you will have to store them somewhere in the SIP part of your
implementation until you have received the 484 and sent the ACK. And,
what do you do with the buffered digits if you, for some reason, receive
a non-484 responses (3xx, for example, or even a 2xx).

This is also a problem (maybe even bigger) in ISUP transparency, where
you may want to sent subsequent ISUP messages before you receive a final
response to the INVITE. The solution was to allow INFO request before
you receive the final response to the INVITE. However, in that case the
specific SIP part of the call is not affected, which it is in the
operlap sending case, so I don't think INFO is a solution here.

Regards,

Christer Holmberg
Ericsson Finland