Hi Vijay,
 
I think that any media specific data should be passed as the fmtp parameter,in 
a way that the SDP does not have to understand them,and regarding the 
offer-answer SDP delaing with the fmtp parameters,this is what rfc 3264 says,
 
"The interpretation of fmtp parameters in an offer depends on the
   parameters.  In many cases, those parameters describe specific
   configurations of the media format, and should therefore be processed
   as the media format value itself would be.  This means that the same
   fmtp parameters with the same values MUST be present in the answer if
   the media format they describe is present in the answer.  Other fmtp
   parameters are more like parameters, for which it is perfectly
   acceptable for each agent to use different values.  In that case, the
   answer MAY contain fmtp parameters, and those MAY have the same
   values as those in the offer, or they MAY be different.  SDP
   extensions that define new parameters SHOULD specify the proper
   interpretation in offer/answer."
 
You should also check your bandwith and p-time atrribute whether you are using 
the same values as negotiated in the offer-answer.
This is what rfc 3264 says 
 
"When sending media, it SHOULD use a packetization
   interval equal to the value of the ptime attribute in the offer, if
   any was present.  It SHOULD send media using a bandwidth no higher
   than the value of the bandwidth attribute in the offer, if any was
   present.  The answerer MUST send using a media format in the offer
   that is also listed in the answer, and SHOULD send using the most
   preferred media format in the offer that is also listed in the
  answer.  In the case of RTP, it MUST use the payload type numbers
   from the offer, even if they differ from those in the answer."




 
Thanks and regards,
 
Shamik Saha
Project Engineer
Voice Protocols
Cell :  +91-9886704155
 

________________________________

From: friend friend [mailto:[email protected]] 
Sent: Tuesday, April 28, 2009 3:11 PM
To: Shamik Saha (WT01 - Telecom Equipment)
Cc: [email protected]
Subject: RE: [Sip-implementors] Query for SDP Negotiation


Hi Shamik,
    Both offer & answer's clk rate frequency and encoding name are same.
 
Each codec has some parameters like Type of codec,Encoding codec name, 
frequency, packetsize,rate.
 
could you please tell me, the packetsize & rate also should be match?
 
if so, we cant able to see the offerer's packet size & rate rite... because 
from the offer we can see payload type, Encoding name and frequency only.
 
 
 correct me if i am wrong
 
Thanks & regards,
vijay


--- On Tue, 28/4/09, [email protected] <[email protected]> wrote:



        From: [email protected] <[email protected]>
        Subject: RE: [Sip-implementors] Query for SDP Negotiation
        To: [email protected]
        Cc: [email protected]
        Date: Tuesday, 28 April, 2009, 8:33 AM
        
        
        Hi Vijay,
         
        you should check whether the same rtpmap value is being used by both 
the offerer and the answerer for the dynamic payloads,for the dynamic payloads 
the value should be in the range 96-127,and atleast one codec should overlap 
among the negotiated codec.
        the payload type mappings from rfc 1890 are as follows,you can try to 
match it with your scenario,since you are facing this problem only with dynamic 
payload types,so perhaps this will help you
         
            PT         encoding      audio/video    clock rate    channels
                         name          (A/V)          (Hz)          (audio)
              _______________________________________________________________
              0          PCMU          A              8000             1
              1          1016             A              8000             1
              2          G721            A               8000            1
              3          GSM            A               8000             1
              4          unassigned    A               8000            1
              5          DVI4            A               8000            1 
              6          DVI4            A              16000           1
              7          LPC             A                8000            1
              8          PCMA         A                8000            1
              9          G722            A                8000            1
              10         L16             A               44100            2
              11         L16             A               44100            1
              12         unassigned    A
              13         unassigned    A
              14         MPA            A              90000        
              15         G728           A                 8000             1
              16--23  unassigned    A
              24         unassigned    V
              25         CelB             V              90000
              26         JPEG            V              90000
              27         unassigned    V
              28         nv                 V              90000
              29         unassigned    V
              30         unassigned    V
              31         H261            V              90000
              32         MPV            V              90000
              33         MP2T          AV            90000
              34--71     unassigned    ?
              72--76     reserved      N/A          N/A           N/A
              77--95     unassigned    ?
              96--127    dynamic       ?
        
         
        Thanks and regards,
         
        Shamik Saha
        Project Engineer
        Voice Protocols
        Cell :  +91-9886704155
         

________________________________

        From: friend friend [mailto:[email protected]] 
        Sent: Monday, April 27, 2009 9:06 PM
        To: Shamik Saha (WT01 - Telecom Equipment)
        Cc: [email protected]
        Subject: RE: [Sip-implementors] Query for SDP Negotiation
        
        
Could you please tell me, is this the codec problem. bcoz particular codec is 
not working

--- On Mon, 27/4/09, [email protected] <[email protected]> wrote:



        From: [email protected] <[email protected]>
        Subject: RE: [Sip-implementors] Query for SDP Negotiation
        To: [email protected]
        Cc: [email protected]
        Date: Monday, 27 April, 2009, 8:56 PM
        
        
        No Vijay that is not a problem because the default value is sendrecv so 
if you do not specify anything it will be taken as send-recv,so if you want it 
to be send-recv it is not mandatory in either offer or answer.
         
         
        Thanks and regards,
         
        Shamik Saha
        Project Engineer
        Voice Protocols
        Cell :  +91-9886704155
         

________________________________

        From: friend friend [mailto:[email protected]] 
        Sent: Monday, April 27, 2009 8:46 PM
        To: Shamik Saha (WT01 - Telecom Equipment)
        Cc: [email protected]
        Subject: RE: [Sip-implementors] Query for SDP Negotiation
        
        
Hi Shamik,
 
    Media negotiation is happening properly. i think the ports are opening 
properly bcoz its working for static codecs. but its not working for dynamic 
codecs.
 
In caller side Direction line is not added. but callee is sending sendrecv in 
200 OK.
 
Caller side Direction line is not present. is this the cause of problem?
 
I think in offer Direction line is not mandatory rite?
 
 
Thanks & regards,
vijay
 
 
 
 


--- On Mon, 27/4/09, [email protected] <[email protected]> wrote:



        From: [email protected] <[email protected]>
        Subject: RE: [Sip-implementors] Query for SDP Negotiation
        To: [email protected]
        Cc: [email protected]
        Date: Monday, 27 April, 2009, 8:11 PM
        
        
        Hi Vijay,
        
        There can be many reasons for a one way speech-path,
        
        You need to check the SDP negotiation properly,whether both the sides 
are sening send-recv or not,
        
        Are the codecs matching?
        
        Then you need to check your application,whether it is opening the send 
and receive ports properly or not.
        
        A look into the negotiated SDP will tell whether the problem is with 
the SDP negotiation or the application.
        
        
        
        
        Thanks and regards,
        
        Shamik Saha
        Project Engineer
        Voice Protocols
        Cell :  +91-9886704155
        
        -----Original Message-----
        From: [email protected] 
<http://in.mc88.mail.yahoo.com/mc/[email protected]>
  [mailto:[email protected] 
<http://in.mc88.mail.yahoo.com/mc/[email protected]>
 ] On Behalf Of friend friend
        Sent: Monday, April 27, 2009 7:57 PM
        To: ext Peter Nijhuis; sip fourm; Somesh (NSN - IN/Bangalore)Shanbhag
        Subject: Re: [Sip-implementors] Query for SDP Negotiation
        
        Dear Folks,
                Thank you for useful responses.
         
        Please clarify one more query.
         
        In case, Both side(caller & callee) call is established and RTP(Both 
side iLBC) also flowing successfully but one side audio is coming and the other 
side audio is not coming.
         
        so what would be the problem(Other than mic bcoz mic is working 
properly)?
         
        Thanks & Regards,
        vijay 
         
         
        
        --- On Mon, 27/4/09, Shanbhag, Somesh (NSN - IN/Bangalore) 
<[email protected] 
<http://in.mc88.mail.yahoo.com/mc/[email protected]> > wrote:
        
        
        From: Shanbhag, Somesh (NSN - IN/Bangalore) <[email protected] 
<http://in.mc88.mail.yahoo.com/mc/[email protected]> >
        Subject: Re: [Sip-implementors] Query for SDP Negotiation
        To: "ext Peter Nijhuis" <[email protected] 
<http://in.mc88.mail.yahoo.com/mc/[email protected]> >, 
"ext friend friend" <[email protected] 
<http://in.mc88.mail.yahoo.com/mc/[email protected]> >, "sip 
fourm" <[email protected] 
<http://in.mc88.mail.yahoo.com/mc/[email protected]>
 >
        Date: Monday, 27 April, 2009, 7:09 PM
        
        
        Yeah, that is even better .. .what I thought was since CALLEE had 
already replied not-in-protocol-way, CALLER may terminate the dialog.
        
        Somesh
        
        -----Original Message-----
        From: ext Peter Nijhuis [mailto:[email protected] 
<http://in.mc88.mail.yahoo.com/mc/[email protected]> ]
        Sent: Monday, April 27, 2009 7:00 PM
        To: Shanbhag, Somesh (NSN - IN/Bangalore); ext friend friend; sip fourm
        Subject: RE: [Sip-implementors] Query for SDP Negotiation
        
        I think Callee should respond with 415 unsupported media type, since it 
is not supporting media types 102, 0, 8 or 106.
        
        Met vriendelijke groet, with kind regards, mit freundlichen Gruß
            
        Peter Nijhuis
        
        
          
        > -----Original Message-----
        > From: [email protected] 
<http://in.mc88.mail.yahoo.com/mc/[email protected]>
  [mailto:sip-
        > [email protected] 
<http://in.mc88.mail.yahoo.com/mc/[email protected]>
 ] On Behalf Of Shanbhag,
        > Somesh (NSN - IN/Bangalore)
        > Sent: maandag 27 april 2009 15:07
        > To: ext friend friend; sip fourm
        > Subject: Re: [Sip-implementors] Query for SDP Negotiation
        >
        > The basic thing is CALLEE has to take the subset of codecs offered by
        > CALLER and reply back.
        > But in your case, CALLEE is replying with different set of codecs (97
        > 101) in reply to CALLER codecs  ( 102 0 8 106 ) IMHO, since the
        > capabilities mis-match, immdiately end the call using BYE / CANCEL
        > which ever is relevant.
        >
        >
        > Somesh
        >
        > -----Original Message-----
        > From: [email protected] 
<http://in.mc88.mail.yahoo.com/mc/[email protected]>
  [mailto:sip-
        > [email protected] 
<http://in.mc88.mail.yahoo.com/mc/[email protected]>
 ] On Behalf Of ext friend
        > friend
        > Sent: Monday, April 27, 2009 2:59 PM
        > To: sip fourm
        > Subject: [Sip-implementors] Query for SDP Negotiation
        >
        > Dear Folks,
        >        I have doubt in the following scenario.
        >
        > Caller's sdp :
        >
        > v=0
        > o=- 1234 1 IN IP4 10.10.20.35
        > s=-
        > c=IN IP4 10.10.20.35
        > t=0 0
        > m=audio 12000 RTP/AVP 102 0 8 106
        > a=rtpmap:102 iLBC/8000
        > a=rtpmap:0 PCMU/8000
        > a=rtpmap:8 PCMA/8000
        > a=rtpmap:106 telephone-event/8000
        >
        >
        > Callee's negotiated sdp :
        >
        > v=0
        > o=- 3449811996 3449811996 IN IP4 10.10.20.4 s=SJphone c=IN IP4
        > 10.10.20.4 t=0 0 m=audio 49164 RTP/AVP 97 101 c=IN IP4 10.10.20.4
        > a=rtpmap:97 iLBC/8000
        > a=rtpmap:101 telephone-event/8000
        > a=fmtp:101 0-16
        > a=setup:active
        > a=sendrecv
        >
        > In this case,Is callee's negotiation method is wrong?
        >
        > Callee should send like m=audio 49164 RTP/AVP 102 106 rite?
        >
        > In this case, after call establishment,
        >              from caller sending RTP using 102 (UnKnown)
        >              from callee sending RTP using 97 (iLBC)
        >
        > So caller hearing callee's audio but callee not able to hear caller's
        > audio.
        >
        > please clarify this issue.
        >
        > Thanks & Regards,
        > vijay
        >
        >
        >       Bring your gang together. Do your thing. Find your favourite
        >Yahoo! group at http://in.promos.yahoo.com/groups/
        > _______________________________________________
        > Sip-implementors mailing list
        > [email protected] 
<http://in.mc88.mail.yahoo.com/mc/[email protected]>
 
        > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
        >
        > _______________________________________________
        > Sip-implementors mailing list
        > [email protected] 
<http://in.mc88.mail.yahoo.com/mc/[email protected]>
 
        > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
        
        _______________________________________________
        Sip-implementors mailing list
        [email protected] 
<http://in.mc88.mail.yahoo.com/mc/[email protected]>
 
        https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
        
        
        
              Explore your hobbies and interests. Go to 
http://in.promos.yahoo.com/groups/
        _______________________________________________
        Sip-implementors mailing list
        [email protected] 
<http://in.mc88.mail.yahoo.com/mc/[email protected]>
 
        https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
        
        Please do not print this email unless it is absolutely necessary.
        
        The information contained in this electronic message and any 
attachments to this message are intended for the exclusive use of the 
addressee(s) and may contain proprietary, confidential or privileged 
information. If you are not the intended recipient, you should not disseminate, 
distribute or copy this e-mail. Please notify the sender immediately and 
destroy all copies of this message and any attachments.
        
        WARNING: Computer viruses can be transmitted via email. The recipient 
should check this email and any attachments for the presence of viruses. The 
company accepts no liability for any damage caused by any virus transmitted by 
this email.
        
        www.wipro.com
        


________________________________

        Bollywood news, movie reviews, film trailers and more! Click here. 
<http://in.rd.yahoo.com/tagline_movies_1/*http://in.movies.yahoo.com/?wm=n/>  
        Please do not print this email unless it is absolutely necessary. 
        The information contained in this electronic message and any 
attachments to this message are intended for the exclusive use of the 
addressee(s) and may contain proprietary, confidential or privileged 
information. If you are not the intended recipient, you should not disseminate, 
distribute or copy this e-mail. Please notify the sender immediately and 
destroy all copies of this message and any attachments. 
        WARNING: Computer viruses can be transmitted via email. The recipient 
should check this email and any attachments for the presence of viruses. The 
company accepts no liability for any damage caused by any virus transmitted by 
this email. 
        www.wipro.com 


________________________________

        Bollywood news, movie reviews, film trailers and more! Click here. 
<http://in.rd.yahoo.com/tagline_movies_1/*http://in.movies.yahoo.com/?wm=n/>  
        Please do not print this email unless it is absolutely necessary. 
        The information contained in this electronic message and any 
attachments to this message are intended for the exclusive use of the 
addressee(s) and may contain proprietary, confidential or privileged 
information. If you are not the intended recipient, you should not disseminate, 
distribute or copy this e-mail. Please notify the sender immediately and 
destroy all copies of this message and any attachments. 
        WARNING: Computer viruses can be transmitted via email. The recipient 
should check this email and any attachments for the presence of viruses. The 
company accepts no liability for any damage caused by any virus transmitted by 
this email. 
        www.wipro.com 


________________________________

Bollywood news, movie reviews, film trailers and more! Click here. 
<http://in.rd.yahoo.com/tagline_movies_1/*http://in.movies.yahoo.com/?wm=n/> 

Please do not print this email unless it is absolutely necessary. 

The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email. 

www.wipro.com
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to