headers
Vineet Menon | 1 Mar 2012 08:15
Picon
Gravatar

Re: multiple SDP messages in a single INVITE

The book is..

session initiation protocol (SIP) controlling convergent networks.. by
travis russel...
http://books.google.co.in/books/about/Session_Initiation_Protocol_SIP.html?id=WxXc0coHxyYC&redir_esc=y

pp. 48, paragraph 1
it says and I quote:
"One SIP invite could carry within itself SDP descriptors for more than one
session. This is so when supporting a conference call, as an example."

Is this regarding the relationship between dialog and session?
I mean a conference can have multiple dialog within a single session!

Regards,

Vineet Menon

On 29 February 2012 23:54, praveena ss <ss.praveena <at> gmail.com> wrote:

> Hi Paul...
>
> "RFC 3959-Early Session Disposition Type for SIP" is implemented in
> Packetcable2.0 RSTF solution.
>
> Vineeth............. can u give me the reference the one u read...
>
> Regards,
> Praveen.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
JAYAPRAKASH LAKSHMINARAYANA | 2 Mar 2012 19:55
Picon
Favicon

Is there a SIP header to indicate file URL to MSRP node to send it to destination.

Hi,

I am looking for SIP header where we can specify the file URL in the SIP INVITE or other SIP message from SIP
Application Server [AS] to another SIPUA [MSRP capable] to indicate the MSRP SIPUA to get the file and send
it to the destination.

This is similar to the RFC4240 announcement service where AS would send the "annc and play" info in INVITE to
the MRF. I am looking for a mechanism for AS to tell a SIPUA that is MSRP capable about the URL and MSRP SIPUA
will fetch the file and send it to the destination.

Thanks in advance.

Regards,
 J.P.
Permalink | Reply | 0 comments |
headers
praveena ss | 2 Mar 2012 20:09
Picon

Re: multiple SDP messages in a single INVITE

Hi vineet,

i read the paragraph in that book. the statement is contradictory because
the example which he talks about multiple m= lines i.e., media descriptions
with single session description which won't match the  the mentioned
statement - ....There could more than one session description within a
single SIP message.

As per my understanding, multiple session description will appear in a SIP
message(using content-disposition header for boundary puposes) when there
is a early media concept comes.

Instead of adding multiple session description in a single sip message,
send re-invite with different session/media description as many times as
you want.

I hope i gave sufficient information w.r.t your doubt.

Regards,
Praveen

On Thu, Mar 1, 2012 at 12:45 PM, Vineet Menon <mvineetmenon <at> gmail.com>wrote:

> The book is..
>
> session initiation protocol (SIP) controlling convergent networks.. by
> travis russel...
> http://books.google.co.in/books/about/Session_Initiation_Protocol_SIP.html?id=WxXc0coHxyYC&redir_esc=y
>
> pp. 48, paragraph 1
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vineet Menon | 6 Mar 2012 08:19
Picon
Gravatar

Capability negotiation control

Hi,

Say UAC sends H.261, 263,264 in offer, and now UAS wants to select one
among them. UAS supports all three.

Now, can UAS send all three codec it supports or it sends only the one
preferred by it in the response?

UAC -------------------------INVITE/H.261,H.263, H.264------------------->
UAS
UAC <-----------------------200 OK/
???????------------------------------------  UAS

Regards,

Vineet Menon
Permalink | Reply | 9 comments |
headers
Tarun2 Gupta | 6 Mar 2012 08:39
Favicon

Re: Capability negotiation control


Regards,
Tarun Gupta
-----Original Message-----
From: sip-implementors-bounces <at> lists.cs.columbia.edu
[mailto:sip-implementors-bounces <at> lists.cs.columbia.edu] On Behalf Of Vineet Menon
Sent: Tuesday, March 06, 2012 12:50 PM
To: Sip-implementors <at> lists.cs.columbia.edu; opalvoip-devel
Subject: [Sip-implementors] Capability negotiation control

Hi,

Say UAC sends H.261, 263,264 in offer, and now UAS wants to select one
among them. UAS supports all three.

Now, can UAS send all three codec it supports or it sends only the one
preferred by it in the response?

UAC -------------------------INVITE/H.261,H.263, H.264------------------->
UAS
UAC <-----------------------200 OK/
???????------------------------------------  UAS

Regards,

Vineet Menon
_______________________________________________
Sip-implementors mailing list
Sip-implementors <at> lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tarun2 Gupta | 6 Mar 2012 08:39
Favicon

Recall: Capability negotiation control

Tarun2 Gupta would like to recall the message, "[Sip-implementors] Capability negotiation control".

===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================
Permalink | Reply | 0 comments |
headers
Tarun2 Gupta | 6 Mar 2012 08:42
Favicon

Re: Capability negotiation control

Hi Vineet

The UAS can send all the supported codecs in the answer. See the following excerpt from RFC 3264

5.1 Unicast Streams

The list of media formats for each media stream conveys two pieces of information, namely the set of formats
(codecs and any parameters associated with the codec, in the case of RTP) that the offerer is capable of
sending  and/or receiving (depending on the direction attributes), and, in the case of RTP, the RTP
payload type numbers used to identify those formats.  If multiple formats are listed, it means that the
offerer is capable of making use of any of those formats during the session.  In other words, the answerer
MAY change formats in the middle of the session, making use of any of the formats listed, without sending a
new offer.

Regards,

Tarun Gupta

Aricent

-----Original Message-----
From: sip-implementors-bounces <at> lists.cs.columbia.edu
[mailto:sip-implementors-bounces <at> lists.cs.columbia.edu] On Behalf Of Vineet Menon
Sent: Tuesday, March 06, 2012 12:50 PM
To: Sip-implementors <at> lists.cs.columbia.edu; opalvoip-devel
Subject: [Sip-implementors] Capability negotiation control

Hi,

Say UAC sends H.261, 263,264 in offer, and now UAS wants to select one
(Continue reading)

Permalink | Reply | 0 comments |
headers
Abhishek Chattopadhyay | 6 Mar 2012 09:40
Picon
Favicon

Re: Capability negotiation control

Hi Vineet,

While answering to the offer, the UAS can choose to either send one codec
which it is willing to both send and receive, or it can choose to send all
of supported codecs (which has arrived in offer) in an order which would
correspond the preference order of codecs at its end (uas end). 

Abhishek.

-----Original Message-----
From: sip-implementors-bounces <at> lists.cs.columbia.edu
[mailto:sip-implementors-bounces <at> lists.cs.columbia.edu] On Behalf Of Vineet
Menon
Sent: Tuesday, March 06, 2012 12:50 PM
To: Sip-implementors <at> lists.cs.columbia.edu; opalvoip-devel
Subject: [Sip-implementors] Capability negotiation control

Hi,

Say UAC sends H.261, 263,264 in offer, and now UAS wants to select one
among them. UAS supports all three.

Now, can UAS send all three codec it supports or it sends only the one
preferred by it in the response?

UAC -------------------------INVITE/H.261,H.263, H.264------------------->
UAS
UAC <-----------------------200 OK/
???????------------------------------------  UAS
(Continue reading)

Permalink | Reply | 0 comments |
headers
bruno.chatras | 5 Mar 2012 17:18

Doubt on MIME body [RFC-3204]

Hello,

I have some doubts about the use of the Content-Length when a sip
message contains a multi-part body. A previous and quite old discussion
on this mailing list has clarified that the Content-Length associated
with the "Content-Type = multipart/mixed" tells the length of the
complete body of the sip message.

https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-March/0187
89.html

However, I have recently eared different opinions as to whether
additional Content-Length header fields may also be associated to
individual parts of the multi-part body.  I don't see any need for
adding such fields but I'm wondering whether doing that should even be
considered an error?

Best Regards,

BC
Permalink | Reply | 0 comments |
headers
Robert Jongbloed | 6 Mar 2012 09:18
Picon

Re: [Opalvoip-devel] Capability negotiation control

It can, but it is, IMHO, a complete pain!

The specification actually says that the selection of codec is not really
completed until the RTP packets arrive.

Actually, a strict interpretation (I think) of the specification means at
any time during the session it could send a frame of H.263, then a frame of
H.264, then a frame of H.261! But that vanishingly unlikely to work in
practice and no one would be insane enough to do it. J

I know there are some implementations that do exactly this for audio. The
OPAL implementation unfortunately is not designed to wait till the first RTP
packet arrives before creating codecs, starting video grabbers, blah, blah,
blah. It does it when the 200 OK arrives. So, OPAL gets around the ambiguity
by immediately sending a re-INVITE selecting one of the codecs the remote
answered with. We end up with:

INVITE  H.264, H.263, H.261

200 OK  H.264, H.263

Re-INVITE H.264

200 OK H.264

Robert Jongbloed

OPAL/OpenH323/PTLib Architect and Co-founder.

From: Vineet Menon [mailto:mvineetmenon <at> gmail.com]
(Continue reading)

Permalink | Reply | 1 comment |

Gmane