Subject: [SIP] Re: Re Mapping of ISUP overlap signalling to SIP

From: "Wayne Cutler" <[email-masked]>
Date: Tue, 26 Jun 2001 13:19:20 +0100

>Hello,

>There have been millons of mails sent to the mailins list in the past
>discussing exactly what you are proposing. Besides, this has been
>presented in several WG meetings.

>Feel free to check the archives to find more information about this.

Whilst here has been a good deal of discussion on the general topic (over at
least 3 threads), the vast majority
were concerned with including the overlap digits in various SIP headers.
Therefore, there hasn't been a great deal
of discussion about making the SIP headers independent of the overlap digits. I
do recall your presentation in the last
WG meeting but that suggested sending multiple INVITEs and (as I recall) there
was nothing said about the option of
making the SIP headers independent of the overlap digits.

So, for limited scenarios, I fail to see why it is wrong/improper to make the
headers independent of the overlap digits. Such an
approach is workable and  does not require any changes to the SIP protocol. So
why can't it be added as another option, with a
suitable health warning about its limited applicability?

Wayne.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 26 Jun 2001 18:02:55 +0300

Hello Wayne,
 
Sending further digits in INFOs without modifying any header was
presented in the SIP WG meeting (the presentation you are referring to).
It is not a good idea because SIP servers that provide services will
usually inspect the headers of the INVITE in order to know which service
should be applied.

Therefore, if the INVITE does not contain all the information in the
headers, SIP proxies that provide services will have to be made aware of
the INFO approach. That is, they will have to know that an INFO might
carry additional digits, and the service logic in the proxy will have to
be extended.

Using INVITEs all the time solves this problem.

Best regards,

Gonzalo

> Wayne Cutler wrote:
> --
> Gonzalo Camarillo                    Phone :   +1 212 939 71 71
> Columbia University                  Mobile:  +358 40 702 35 35
> 472 Computer Science Building        Fax   :  +358  9 299 30 52
> 1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
> New York, NY 10027
> USA                              [email-masked]

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

---

From: "Mark Watson" <[email-masked]>
Date: Tue, 26 Jun 2001 17:32:28 +0100

Wayne,

Your proposal presumes that the incoming PSTN/SIP gateway can identify the
outgoing SIP/PSTN gateway. If this knowledge is instead in an intermediate
SIP proxy, then the digit information will need to be in the SIP headers,
because the proxy will not examine the ISUP payload.

IMO, once the INVITE has reached the o/g SIP/PSTN gateway, it would be of
value for subsequent digits to travel in INFOs (a backwards indication that
this was allowed would be needed at this point).

But as Gonzalo says this has been discussed ad nauseum on this list, to no
clear conclusion AFAIK.

Regards,

Mark Watson
Nortel Networks

> -----Original Message-----
> From: Wayne Cutler [mailto:[email-masked]]
> Sent: 26 June 2001 13:19
> To: Gonzalo Camarillo
> Cc: [email-masked]
> Subject: [SIP] Re: Re Mapping of ISUP overlap signalling to SIP
> 
> 
> 
> 
> >Hello,
>

---

From: "Wayne Cutler" <[email-masked]>
Date: Wed, 27 Jun 2001 09:09:12 +0100

Mark,

Yes, you're correct that my proposal does assume that the i/c GW can identify
the o/g GW.

So, whilst not being a general case, it is still a valid scenario for a limited
applicability.

I agree that there hasn't been a conclusion and as it stands it appears that
ETSI ISUP gets forced to work
en-bloc by default.

Regards, Wayne.

"Mark Watson" <[email-masked]> on 26/06/2001 17:32:28

                                                              

 To:      Wayne Cutler/MAIN/MC1@MCMAIN, Gonzalo Camarillo     
          <[email-masked]>                 
                                                              
 cc:      [email-masked]                             

 Subject: RE: [SIP] Re: Re Mapping of ISUP overlap signalling 
          to SIP                                              

Wayne,

Regards,

Mark Watson
Nortel Networks