Subject: RE: [Sipping] nit review of draft-ietf-sip-isup-03.txt

From: Igor Slepchin <[email-masked]>
Date: Wed, 26 Sep 2001 10:55:21 -0400

That's precisely the source of the confusion that I tried to point to: the
draft is not really clear about what network entities may be involved in
call setup and maintenance and how they should act on ISUP payloads. 

For example, if the UAS is a gateway, it should certainly understand
multipart/mime and may only drop ISUP if it doesn't understand the specific
variant in the message. If UAS is a pure SIP endpoint, it may not even
understand multipart/mime, in which case the media flow will not be
established.

Thank you,
Igor Slepchin

> -----Original Message-----
> From: Michael Hammer [mailto:[email-masked]]
> 
> Gonzalo,
> 
> So you are saying that:
> 
> if there is a proxy in the network between two PSTN Gateways, 
> it will not 
> parse the body, but will propagate an ISUP MIME attachment 
> forward; but,
> 
> if there is any B2BUA in the network between two PSTN 
> Gateways, it will 
> drop the ISUP MIME attached.
> 
> That could potentially create problems.  Does that rely on 
> the assumption 
> of a specific implementation?
> 
> Then, I assume, for completeness, that an experimental form 
> of SDP or any 
> other new MIME body part would also be dropped, if it is not 
> recognized.
> 
> Mike

_______________________________________________
Sipping mailing list  http://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: Gonzalo Camarillo <[email-masked]>
Date: Wed, 26 Sep 2001 18:54:17 +0300

Hello,

> understand multipart/mime, in which case the media flow will not be

The negotiation of what UAs can "Accept" is carried out using
vanilla-SIP. That is, if that UA does not understand MIME will return a
"Not Acceptable Here" response" with an "Accept" header indicating what
can he actually receive. Then, the UAC will not send any encapsulated
ISUP anymore. The media flow will, however, be established.

In another scenario the gateway can encapsulate ISUP, but the last proxy
handling the INVITE within its organization might want to remove it or
encrypt it... I believe we talked about that in the draft (under
security considerations).

Anyway, thanks for the comment. We will try to clarify this in the final
version of the draft.

Best regards,

Gonzalo

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