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:[email protected]] 
Sent: Tuesday, 6 March 2012 6:20 PM
To: [email protected]; opalvoip-devel
Subject: [Opalvoip-devel] 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
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to