Subject: Re: [SIP] Overlap Sending

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

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 12:43:36 +0200

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