Subject: Question about SIP message

From: "Stanislav S. Timinsky" <[email-masked]>
Date: Mon, 31 Jan 2000 13:34:09 +0300

Hello,

 I have the questions about SIP test message (test1.txt) on
 http://www.cs.columbia.edu/~hgs/sip/bakeoff2/testmsg.html site.

 The text of this message is:

-----------------------------
INVITE sip:[email-masked] SIP/2.0
TO :
 sip:[email-masked] ;   tag    = 1918181833n
From   : "J Rosenberg \\\"" <sip:[email-masked]>
  ;
  tag = 98asjd8
CaLl-Id
 : [email-masked]
cseq: 8
  INVITE
Via  : SIP  /   2.0 
 /UDP 
    135.180.130.133
Subject :
NewFangledHeader:   newfangled value
 more newfangled value
Content-Type: application/sdp
v:  SIP  / 2.0  / TCP     12.3.4.5   ;
  branch  =   9ikj8  ,
 SIP  /    2.0   / UDP  1.2.3.4   ; hidden   
m:"Quoted string \"\"" <sip:[email-masked]> ; newparam = newvalue ;
  secondparam = secondvalue  ; q = 0.33
  (((nested comments) and (more)))   ,
 tel:4443322

v=0
o=mhandley 29739 7272939 IN IP4 126.5.4.3
c=IN IP4 135.180.130.88
m=audio 492170 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
-----------------------------

1. Why tags in the TO and FROM headers have not hex format?
2. Why SDP body hasn't mandatory fields (session-name-field and
                                         time-fields)?
-- 
Best regards,
 Stanislav S. Timinsky              mailto:[email-masked]

---

From: Igor Slepchin <[email-masked]>
Date: Mon, 31 Jan 2000 19:05:36 -0500

"Stanislav S. Timinsky" wrote:
> <..> 

I guess this is in line with the general rule that you should strictly
adhere to the protocol when generating your own messages but be lenient
when parsing received messages. This approach greatly increases the
chances of interoperability among different vendors' implementations.

Returning to the example you mentioned:

1. The only real requirement for the tag parameter is its uniqueness and
UUIDs are just a way to enforce this. Thus, having a non-hex tag value
does not represent a major error and should probably be accepted.

2. SDP was initially designed for multicast session announcements over
SAP. Hence, some of the parameters listed as required in RFC2327 are
less vital for SIP session descriptions, and some don't even make much
sense in SIP context. E.g., SDP session name duplicates the
functionality of SIP Subject header, and UAs are likely to assume that
the media exchange starts whenever the call setup is complete and ends
whenever a BYE is sent, thus making time field unnecessary.

---
Igor Slepchin

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 31 Jan 2000 21:22:33 -0500

Igor Slepchin wrote:

> whenever a BYE is sent, thus making time field unnecessary.

While this may be true in current "make-it-look-like-a-phone"
implementations, there are a number of useful applications where SDP and
SIP information convey different information. For example, the spec
gives the example of an invitation to a broadcast session. The subject
of the invitation may well be different from the "Internet TV" session
title. Similarly, for the date, where scheduling calls into the future
can be a rather useful group coordination tool.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs