In an IMS network, If an offer contains information against the policy (e.g., a forbidden codec) the CSCF returns a 488 (Not Acceptable Here) response with an SDP body describing either the policy or a subset of it. For instance, the SDP body can contain a session description that would have been an acceptable offer (e.g., the forbidden codec is removed from the list of codecs). Example: The S-CSCF receives an INVITE request with the session description indicated below, which contains a video stream in addition to an audio stream.
v=0 o=- 2790844676 2867892807 IN IP6 1080::8:800:200C:417A s=- c=IN IP6 1080::8:800:200C:417A t=0 0 m=audio 20000 RTP/AVP 97 96 b=AS:25.4 a=curr:qos local none a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos none remote sendrecv a=rtpmap:97 AMR a=fmtp:97 mode-set=0,2,5,7; maxframes=2 a=rtpmap:96 telephone-event m=video 20002 RTP/AVP 31 The S-CSCF returns a 488 (Not Acceptable Here) response, containing the session description indicated below. This session description includes only an audio stream, indicating that the user cannot establish video streams. v=0 o=S-CSCF 2790844634 2867892823 IN IP6 1080::8:800:200C:2A2F s=- c=IN IP6 1080::8:800:200C:2A2F t=0 0 m=audio 0 RTP/AVP 97 96 b=AS:25.4 a=rtpmap:97 AMR a=fmtp:97 mode-set=0,2,5,7; maxframes=2 a=rtpmap:96 telephone-event Generally in all networks, The a= field (optional) contains attributes of the preceding media session. If not fully understood by a SDP user, the attribute field can be ignored. There can be one or more attribute fields for each media payload type listed in the media field. I hope this info is useful. Best regards, Harpreet --- "Gummadidala, Ravi" <[EMAIL PROTECTED]> wrote: > Let us say A makes an SDP offer which looks like > > > m=audio 49120 RTP <http://www.voip-telephony.org/rfc/avt> /AVP 97 > a=rtpmap:97 EVRC/8000 > a=fmtp:97 maxinterleave=2 > m=video 49170/2 RTP/AVP 98 > a=rtpmap:98 MP4V-ES/90000 > a=fmtp:98 profile-level-id=1;config=XYZ > > My understanding is that these fmtp parameters are specific to the UA > and not to the session; however I have a colleague who claims that > these > are properties of the session i.e. for a sendrecv channel both UAs > must > use the same fmtp values so for e.g. B which receives this offer must > also use maxinterleave of 2, etc. But, I think maxinterleave is a > property of the UA and need not be the same for both A and B. Same > thing > with the MP4 vol header which is an encoder property and hence need > not > be the same for both end points in a one-to-one session. So I believe > this is a valid SDP answer to the above offer > > m=audio 49120 RTP <http://www.voip-telephony.org/rfc/avt> /AVP 97 > a=rtpmap:97 EVRC/8000 > a=fmtp:97 maxinterleave=5 > m=video 49170/2 RTP/AVP 98 > a=rtpmap:98 MP4V-ES/90000 > a=fmtp:98 profile-level-id=1;config=ABC > > Per my colleague, the above is not a valid SDP answer to the offer. > The > RFCs seem very vague about the interpretation of these fmtp > parameters. > Is this not a source of interop nightmares where vendor > implementations > depend on their interpretation of these ambiguous specs or am I > missing > something fundamental here? Your input is most appreciated. > > Thanks, > -Ravi. > > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
