Subject: [Sipping] SIP-ISUP interworking draft

From: "Alexeitsev, D" <[email-masked]>
Date: Tue, 16 Jul 2002 13:45:32 +0200

Hello All,

a question about the mapping of 183 to ACM/CPG

The 183 response is often use for the sending of the SDP in the resource reservation and precondition cases. This complicates the actual mapping of this response as one would have somehow to differentiate between the use of 183 for session progress indication and resource reservation.

The question is whether it is possible to separate the use of 183 as the general SDP transport and the progress indication by defining a new general provisional response or having any other indication?

Greeting,
Denis Alexeitsev

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Mark Watson" <[email-masked]>
Date: Tue, 16 Jul 2002 14:04:03 +0100

Alex,

I think there is a problem with any phrase like "<SIP message name> mapping
to <ISUP message name>"

The SIP Message names do not always capture the same semantics as do ISUP
message names.

What you are looking for is a catchy term (let's say "foo") for "the first
SIP response to the INVITE containing a To tag, which arrives after, or
indicates that, pre-conditions have been met."

This message indicates that the called party has been found, and so can
trigger ACM. It may be the first 183 (if no pre-conditions, or if this 183
indicates pre-conditions met) or it may be a 18x message after
pre-conditions have been met and confirmed using UPDATE.

Then you can talk about "foo mapping to ACM/CPG".

I think there are some other cases where the stimulus required to trigger a
given ISUP message could arrive in one of several SIP messages e.g. anything
which is triggered by confirmation that preconditions have been met, since
this confirmation could arrived in 18x, UPDATE, 200 OK to UPDATE, PRACK or
could even be in the INVITE.

...Mark

> -----Original Message-----
> From: Alexeitsev, D [mailto:[email-masked]]
> Sent: 16 July 2002 12:46
> To: [email-masked]
> Subject: [Sipping] SIP-ISUP interworking draft
> 
> 
> Hello All,
> 
> The 183 response is often use for the sending of the SDP in 
> the resource reservation and precondition cases. This 
> complicates the actual mapping of this response as one would 
> have somehow to differentiate between the use of 183 for 
> session progress indication and resource reservation.
> 
> The question is whether it is possible to separate the use of 
> 183 as the general SDP transport and the progress indication 
> by defining a new general provisional response or having any 
> other indication?
> 
> Greeting,
> Denis Alexeitsev
>

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 17 Jul 2002 00:05:15 +0900

forgot to reply all...

Begin forwarded message:

> From: Rohan Mahy <[email-masked]>
> Date: Wed Jul 17, 2002  12:04:35 AM Asia/Tokyo
> To: "Alexeitsev, D" <[email-masked]>
> Subject: Re: [Sipping] SIP-ISUP interworking draft
>
> Hi,
>
> The meaning of 183 is pretty well specified in 3261:
>
> The 183 (Session Progress) response is used to convey information about 
> the progress of the call that is not otherwise classified. The 
> Reason-Phrase, header fields, or message body MAY be used to convey 
> more details about the call progress.
>
> The fact that 183 (like other 18x responses and 2xx responses to an 
> INVITE) can contain an SDP offer or answer is completely orthogonal to 
> the semantics of the response code.
>
> thanks,
> -rohan
>
> On Tuesday, July 16, 2002, at 08:45 PM, Alexeitsev, D wrote:
>
>> Hello All,
>>
>> The 183 response is often use for the sending of the SDP in the 
>> resource reservation and precondition cases. This complicates the 
>> actual mapping of this response as one would have somehow to 
>> differentiate between the use of 183 for session progress indication 
>> and resource reservation.
>>
>> The question is whether it is possible to separate the use of 183 as 
>> the general SDP transport and the progress indication by defining a 
>> new general provisional response or having any other indication?
>>
>> Greeting,
>> Denis Alexeitsev
>>

---

From: "Alexeitsev, D" <[email-masked]>
Date: Wed, 17 Jul 2002 13:27:12 +0200

Hello Chris
 
Thanks for the clarification. The issue with mapping of 183 to ACM/CPG in manyfolks case is resolved.
 
But I still believe that there is a need to define something along the UPDATE lines but in the backward direction. Some provisional response (not 183), that is used for bearer control, but has no impact on the call/dialog state. That would be very helpful in many scenarios and I think that it could be a part of the manyfolks draft.
 
Greeting,
Denis Alexeitsev   

-----Ursprüngliche Nachricht-----
Von: Chris Hogg [mailto:[email-masked]]
Gesendet am: Mittwoch, 17. Juli 2002 13:14
An: 'Alexeitsev, D'; [email-masked]
Betreff: RE: [Sipping] SIP-ISUP interworking draft

Hi Denis, 

I think you're talking about an (ISUP to SIP) Manyfolks call flow versus a Non-Manyfolks call flow. Suppose in both cases you are using reliable provisional responses. In the Manyfolks case, you will receive a 183 Session Progress with SDP containing either an offer or an answer that also contains preconditions.  In the non-manyfolks case you will receive a 183 or other 18x response also containing SDP which is either an offer or an answer but that does not contain precondition SDP.  If I understand correctly, you're worry is that in both cases the 183 would map to an ACM at the ISUP-SIP gateway.  This should not be the case.  Indeed the very fact that the manyfolks reliable provisional response contained precondition SDP (which the gateway looked at and determined that the preconditions were not met) means that the ACM should not be sent.  Thus there is a definite difference through which we can determine whether or not the ACM should be sent when we receive a 183 Session Pro!
gress.

As Mark has previously pointed out it is not possible to say things like "183 maps to ACM" without qualifying what you mean by the 183.  Instead you need to say things like - "the first reliable provisional response containing no preconditions or (if it contains preconditions) with preconditions met)" or a later 18x message after preconditions have been met and confirmed using UPDATE.

Thanks, 

Cheers 
Chris. 

Chris Hogg 
Nortel Networks (UK)

---

From: "Chris Hogg" <[email-masked]>
Date: Wed, 17 Jul 2002 12:14:13 +0100

Hi Denis,

I think you're talking about an (ISUP to SIP) Manyfolks call flow versus a
Non-Manyfolks call flow. Suppose in both cases you are using reliable
provisional responses. In the Manyfolks case, you will receive a 183 Session
Progress with SDP containing either an offer or an answer that also contains
preconditions.  In the non-manyfolks case you will receive a 183 or other
18x response also containing SDP which is either an offer or an answer but
that does not contain precondition SDP.  If I understand correctly, you're
worry is that in both cases the 183 would map to an ACM at the ISUP-SIP
gateway.  This should not be the case.  Indeed the very fact that the
manyfolks reliable provisional response contained precondition SDP (which
the gateway looked at and determined that the preconditions were not met)
means that the ACM should not be sent.  Thus there is a definite difference
through which we can determine whether or not the ACM should be sent when we
receive a 183 Session Progress.

As Mark has previously pointed out it is not possible to say things like
"183 maps to ACM" without qualifying what you mean by the 183.  Instead you
need to say things like - "the first reliable provisional response
containing no preconditions or (if it contains preconditions) with
preconditions met)" or a later 18x message after preconditions have been met
and confirmed using UPDATE.

Thanks,

Cheers
Chris.

Chris Hogg
Nortel Networks (UK)

-----Original Message-----
From: Alexeitsev, D [mailto:[email-masked]]
Sent: 17 July 2002 10:48
To: [email-masked]
Subject: WG: [Sipping] SIP-ISUP interworking draft

Hello Rohan

So what should a GW do if it gets the 183 with SDP just because the other
side wants the allocation of resources at the GW and no indication on the
ISUP side? It can not distinguish this case from the "real" session progress
information that should be mapped to the ACM/CPG.

My confusion is that because of such wide definition "not otherwise
classified" everybody is using the 183 if they just wand to send SDP in e2e
provisional response.

So it might be better to define an additional e2e provisional response, that
would allow the transportation of SDP without impacting the call/session
state. As such the bearer control and the whole resource reservation has
nothing to do with the session itself.

In my understanding the orthogonality does not mean that the SIP is just the
transport for SDP.  It is still the call/session control protocol. So the
requests and responses are driving the session state and can not be abused
just for the transportation.

Greetings,
Denis Alexeitsev

-----Ursprüngliche Nachricht-----
Von: Rohan Mahy [mailto:[email-masked]]
Gesendet am: Dienstag, 16. Juli 2002 17:05
An: Alexeitsev, D
Betreff: Re: [Sipping] SIP-ISUP interworking draft

Hi,

The 183 (Session Progress) response is used to convey information about 
the progress of the call that is not otherwise classified. The 
Reason-Phrase, header fields, or message body MAY be used to convey more 
details about the call progress.

thanks,
-rohan