Subject: RE: [Sip] Two IP addresses (c= lines) in invite

From: Bilajbegovic Damir <[email-masked]>
Date: Thu, 15 Jan 2004 12:56:40 +0100

Hi,
     Yes I looked for it and I did not see the answer. 
It answers about hawing the lines "c= ..." but it doesn't say how it reacts
when this message is not valid.

	Regards  Damir Bilajbegovic
-----Original Message-----
From: Bernie Hoeneisen [mailto:[email-masked]] 
Sent: Thursday, January 15, 2004 10:54 AM
To: Bilajbegovic Damir
Cc: [email-masked]
Subject: Re: [Sip] Two IP addresses (c= lines) in invite

Hi Damir!

Have you already checked this in RFC 2327 and RFC 3266?

  http://www.ietf.org/rfc/rfc2327 (SDP)
  http://www.ietf.org/rfc/rfc3266 (IPv6 extensions to SDP)

  (Note, that in RFC 3266 there is a typo in section 1, where it refers to
  RFC 2328. It should be RFC 2327.)

According to RFC 2327 (section 6) you can have either one connection 'c= '
line for the whole session or then serveral connection 'c= ' lines per media
'm= ' line.  In the lattter the connection 'c= ' lines must appear after the
media 'm= ' lines.

I just wonder, how many SIP implementations out in the world do handle this
as standardized...

cheers,
 Bernie

On Thu, 15 Jan 2004, Bilajbegovic Damir wrote:

>     If I sent a INVITE message with two IP addresses (i.e. user has
> two IP addresses and on one it should receive messages) what happens? 
> Is it valid and how the terminal or proxy should react on this. (there 
> are c= lines ) And one more additional question: If one c= is IPv6 and 
> another line is c= IPv4 and colleen (B) party is IPv4 what does is do? 
> Will B party (or B
> proxy) reject the message, replay with deleted misunderstood lines, or 
> will put the port numbers on 0. The message invite is down below (I 
> think it should look like this- is it
> good?)
>  Thanks in advance.
>
>             Damir Bilajbegovic
>
> INVITE tel:+1-212-555-2222 SIP/2.0
>
>   ............
>
> v=0
> o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
> s=-
> c=IN IP6 5555::aaa:bbb:ccc:ddd
> t=0 0
> m=video 3400 RTP/AVP 98 99
> b=AS:75
> a=curr:qos local none
> a=curr:qos remote none
> a=des:qos mandatory local sendrecv
> a=des:qos none remote sendrecv
> a=rtpmap:98 H263
> a=fmtp:98 profile-level-id=0
> a=rtpmap:99 MP4V-ES
>
>
> c=IN IP6 5555::aaa:bbb:ccc:eee
> t=0 0
> m=video 3400 RTP/AVP 98 99
> b=AS:75
> a=curr:qos local none
> a=curr:qos remote none
> a=des:qos mandatory local sendrecv
> a=des:qos none remote sendrecv
> a=rtpmap:98 H263
> a=fmtp:98 profile-level-id=0
> a=rtpmap:99 MP4V-ES
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip Use
> [email-masked] for new developments on the application of sip
>

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

---

From: Bernie Hoeneisen <[email-masked]>
Date: Thu, 15 Jan 2004 14:00:59 +0100 (CET)

Hi Damir!

What about:  400 Bad Request

RFC 3261, 21.4.1: "400 Bad Request
                   The request could not be understood due to
                   malformed syntax. ..."

But I have a feeling, that is is not what you are looking for.
Maybe you'd ask the sip-implementors list for current practice on this
issue:  http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Regards,
 Bernie