Subject: RE: [SIP] SIP and SIP-T distinction.

From: [email-masked]
Date: Thu, 26 Oct 2000 12:13:12 -0600

Andy,
Please see notes below.
Aparna

Hi,

I realise that SIP-T is not a new protocol specification but simply details
the methods, standards and tools necessary to enable MGC's to inter operate
via the SIP protocol BUT is there an easy way to distinguish bewteen SIP and
SIP-T messages (i.e. messages with encapsulated ISUP as well as SDP).

For example, will a SIP-T message have its own SIP-VERSION to go in the
request/response header - SIP-T/1.0 ?

No. As you yourself state, SIP-T is not a new protocol. No special analysis 
is required for processing these messages. SIP proxies (and in general, the
IP 
network) do(es) not have to be aware of the fact that the 'signaling is
SIP-T '. 
SIP UAs like MGC UAs and SIP-phones (as defined in the Contexts and 
Architectures document) are the elements that need to take the necessary 
measures to handle the ' SIP-T signaling ' (whether accept and generate ISUP
or
ignore or reject MIME multi-part, etc.)
<<<

Or is the message body is defined as having CONTENT-TYPE of multipart/mixed
can you assume it is a SIP-T message ?  I take it this too much to assume as
there is no doubt other expansions of SIP that use this MIME format for
multiple payloads, or is likely to be so in the future. Also, is it likely
that multipart/mixed may just be used to carry the SDP information on its
own instead of application/sdp ?

A multi-part/mixed payload is  NOT sufficient to establish the identity of
SIP-T and 
precisely for the reason you cite.
<<<

Or is the only way to determine whether there is an ISUP payload is to delve
into the message body and look for CONTENT-TYPE application/isup ?

Finally, is it also tto much to assume that the SDP payload will always
precede the ISUP payload in the message body ?

I do not believe there are any rules that specify the order of the payloads.
<<<

Hopefully, I have not polluted your mailing list with my inane ramblings,
but I have scoured your FAQ section and archives to no avail !!

Thanks for any help anyone is prepared to give.

Andy.
============================
Andrew S Duncan
Agilent Technologies
Tel: 0131 331 7822   Exten: 32822
Mailstop: SQFR&D3
============================

_______________________________________________
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: David Shrader <[email-masked]>
Date: Thu, 26 Oct 2000 22:53:35 -0400

I don't think we should be treating SIP-T as a separate protocol. There just
happen to be additional components to the message and you either understand
them or you don't. If you don't understand something and you don't need to
understand, then ignore it. If you do need to understand it, then reject it.
----------------------------
David Shrader
Master Consultant, Inc.
[email-masked]
http://www.EyeForTheFuture.com

> From: [email-masked]
> Date: Thu, 26 Oct 2000 12:13:12 -0600
> To: [email-masked], [email-masked]
> Subject: RE: [SIP] SIP and SIP-T distinction.
> 
> Andy,
> Please see notes below.
> Aparna
> 
> 
> 
> Hi,
>