Outgoing call issue in iOS application in Linphne

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Outgoing call issue in iOS application in Linphne

Linphone-developers
Hello,

We are facing issue in outgoing calls , calls were not able to go through our provider which we are using , here is reply from our provider , it is related to codec , can you please help us.

Reply from Our provider:

" I checked the samples you have provided and I could observe few things in the calls which have failed.
The main reason for calls failing is because of the mismatch in codec negotiation.
Plivo accepts the call only on PCMU 0 and 8 ( g711).
The calling agent is sending an invite with the codec's 97 98 99 100 0 8 101.
But is missing to send the media attribute description for either 0 or 8, since the codec is not described our servers are rejecting the call.
To fix the issue you will have to send at least one of the codecs in the media attributes only then the calls will be processed"

It there any thing we can change in code to overcome this issue ?


--
Regards,
Vivek Tilva
Application Developer,
US +18572563703 | IN +91 9265391756


_______________________________________________
Linphone-developers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/linphone-developers
Reply | Threaded
Open this post in threaded view
|

Re: Outgoing call issue in iOS application in Linphne

Elisa Nectoux
Hi Vivek,

Thank you for your interest in Linphone.

However, it is not correct to say that Linphone is missing the a=rtpmap attributes for pcmu and pcma, as these attributes are not mandatory.

Please refer to RFC3264 [https://tools.ietf.org/html/rfc3264] An Offer/Answer Model Session Description Protocol, in section 5 "Generating the answer":

In the case of RTP streams, all media descriptions SHOULD contain "a=rtpmap" mappings from RTP payload types to encodings.  If there is no "a=rtpmap", the default payload type mapping, as defined by the current profile in use (for example, RFC 1890 [5]) is to be used.

RFC1890 has been replaced by RFC3551 but still defines PCMU and PCMA with static payload type numbers 0 and 8.

Equipments that require rtpmap for static payload types are hence non-conformant with RFC3264.

In order to workaround this non-conformance, linphone has a build-time option to request rtpmap to be always used in SDP. Just pass -DENABLE_RTP_MAP_ALWAYS_IN_SDP=ON to the cmake command line (or prepare.py).

For your information, the reason why we decided many years ago not to honor the "SHOULD" for static payload types is simply to save bytes in the INVITE or 200 Ok length by removing redundant information. Indeed, there are still many use case where MTU limit is major problem, for example when interoperating with SIP gateways that only support SIP/UDP transport.

Best regards,

Elisa Nectoux
Sales & Marketing

+33 (0)9 52 63 65 05
[hidden email]

Belledonne Communications, the company behind the Linphone project




Le 8 août 2019 à 12:21, Vivek Tilva via Linphone-developers <[hidden email]> a écrit :

Hello,

We are facing issue in outgoing calls , calls were not able to go through our provider which we are using , here is reply from our provider , it is related to codec , can you please help us.

Reply from Our provider:

" I checked the samples you have provided and I could observe few things in the calls which have failed.
The main reason for calls failing is because of the mismatch in codec negotiation.
Plivo accepts the call only on PCMU 0 and 8 ( g711).
The calling agent is sending an invite with the codec's 97 98 99 100 0 8 101.
But is missing to send the media attribute description for either 0 or 8, since the codec is not described our servers are rejecting the call.
To fix the issue you will have to send at least one of the codecs in the media attributes only then the calls will be processed"

It there any thing we can change in code to overcome this issue ?

--
Regards,
Vivek Tilva
Application Developer,
US +18572563703 | IN +91 9265391756

_______________________________________________
Linphone-developers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/linphone-developers


_______________________________________________
Linphone-developers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/linphone-developers
Reply | Threaded
Open this post in threaded view
|

Re: Outgoing call issue in iOS application in Linphne

Linphone-developers
Hi Elisa,

Thanks for this info , really appreciate it.

If you can help me with how to set this  DENABLE_RTP_MAP_ALWAYS_IN_SDP = ON from code (from which file i can set this) , would be great.

Thanks in advance

On Tue, Aug 13, 2019 at 2:51 PM Elisa Nectoux <[hidden email]> wrote:
Hi Vivek,

Thank you for your interest in Linphone.

However, it is not correct to say that Linphone is missing the a=rtpmap attributes for pcmu and pcma, as these attributes are not mandatory.

Please refer to RFC3264 [https://tools.ietf.org/html/rfc3264] An Offer/Answer Model Session Description Protocol, in section 5 "Generating the answer":

In the case of RTP streams, all media descriptions SHOULD contain "a=rtpmap" mappings from RTP payload types to encodings.  If there is no "a=rtpmap", the default payload type mapping, as defined by the current profile in use (for example, RFC 1890 [5]) is to be used.

RFC1890 has been replaced by RFC3551 but still defines PCMU and PCMA with static payload type numbers 0 and 8.

Equipments that require rtpmap for static payload types are hence non-conformant with RFC3264.

In order to workaround this non-conformance, linphone has a build-time option to request rtpmap to be always used in SDP. Just pass -DENABLE_RTP_MAP_ALWAYS_IN_SDP=ON to the cmake command line (or prepare.py).

For your information, the reason why we decided many years ago not to honor the "SHOULD" for static payload types is simply to save bytes in the INVITE or 200 Ok length by removing redundant information. Indeed, there are still many use case where MTU limit is major problem, for example when interoperating with SIP gateways that only support SIP/UDP transport.

Best regards,

Elisa Nectoux
Sales & Marketing

+33 (0)9 52 63 65 05
[hidden email]

Belledonne Communications, the company behind the Linphone project




Le 8 août 2019 à 12:21, Vivek Tilva via Linphone-developers <[hidden email]> a écrit :

Hello,

We are facing issue in outgoing calls , calls were not able to go through our provider which we are using , here is reply from our provider , it is related to codec , can you please help us.

Reply from Our provider:

" I checked the samples you have provided and I could observe few things in the calls which have failed.
The main reason for calls failing is because of the mismatch in codec negotiation.
Plivo accepts the call only on PCMU 0 and 8 ( g711).
The calling agent is sending an invite with the codec's 97 98 99 100 0 8 101.
But is missing to send the media attribute description for either 0 or 8, since the codec is not described our servers are rejecting the call.
To fix the issue you will have to send at least one of the codecs in the media attributes only then the calls will be processed"

It there any thing we can change in code to overcome this issue ?

--
Regards,
Vivek Tilva
Application Developer,
US +18572563703 | IN +91 9265391756

_______________________________________________
Linphone-developers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/linphone-developers


_______________________________________________
Linphone-developers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/linphone-developers
Reply | Threaded
Open this post in threaded view
|

Re: Outgoing call issue in iOS application in Linphne

Elisa Nectoux
Dear Vivek,

For further assistance, I recommend that you subscribe to our development assistance service.

Best regards,

Elisa Nectoux
Sales & Marketing

+33 (0)9 52 63 65 05
[hidden email]

Belledonne Communications, the company behind the Linphone project




Le 13 août 2019 à 11:58, Vivek Tilva <[hidden email]> a écrit :

Hi Elisa,

Thanks for this info , really appreciate it.

If you can help me with how to set this  DENABLE_RTP_MAP_ALWAYS_IN_SDP = ON from code (from which file i can set this) , would be great.

Thanks in advance

On Tue, Aug 13, 2019 at 2:51 PM Elisa Nectoux <[hidden email]> wrote:
Hi Vivek,

Thank you for your interest in Linphone.

However, it is not correct to say that Linphone is missing the a=rtpmap attributes for pcmu and pcma, as these attributes are not mandatory.

Please refer to RFC3264 [https://tools.ietf.org/html/rfc3264] An Offer/Answer Model Session Description Protocol, in section 5 "Generating the answer":

In the case of RTP streams, all media descriptions SHOULD contain "a=rtpmap" mappings from RTP payload types to encodings.  If there is no "a=rtpmap", the default payload type mapping, as defined by the current profile in use (for example, RFC 1890 [5]) is to be used.

RFC1890 has been replaced by RFC3551 but still defines PCMU and PCMA with static payload type numbers 0 and 8.

Equipments that require rtpmap for static payload types are hence non-conformant with RFC3264.

In order to workaround this non-conformance, linphone has a build-time option to request rtpmap to be always used in SDP. Just pass -DENABLE_RTP_MAP_ALWAYS_IN_SDP=ON to the cmake command line (or prepare.py).

For your information, the reason why we decided many years ago not to honor the "SHOULD" for static payload types is simply to save bytes in the INVITE or 200 Ok length by removing redundant information. Indeed, there are still many use case where MTU limit is major problem, for example when interoperating with SIP gateways that only support SIP/UDP transport.

Best regards,

Elisa Nectoux
Sales & Marketing

+33 (0)9 52 63 65 05
[hidden email]

Belledonne Communications, the company behind the Linphone project




Le 8 août 2019 à 12:21, Vivek Tilva via Linphone-developers <[hidden email]> a écrit :

Hello,

We are facing issue in outgoing calls , calls were not able to go through our provider which we are using , here is reply from our provider , it is related to codec , can you please help us.

Reply from Our provider:

" I checked the samples you have provided and I could observe few things in the calls which have failed.
The main reason for calls failing is because of the mismatch in codec negotiation.
Plivo accepts the call only on PCMU 0 and 8 ( g711).
The calling agent is sending an invite with the codec's 97 98 99 100 0 8 101.
But is missing to send the media attribute description for either 0 or 8, since the codec is not described our servers are rejecting the call.
To fix the issue you will have to send at least one of the codecs in the media attributes only then the calls will be processed"

It there any thing we can change in code to overcome this issue ?

--
Regards,
Vivek Tilva
Application Developer,
US +18572563703 | IN +91 9265391756

_______________________________________________
Linphone-developers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/linphone-developers



_______________________________________________
Linphone-developers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/linphone-developers
Reply | Threaded
Open this post in threaded view
|

Re: Outgoing call issue in iOS application in Linphne

Linphone-developers
Hi Elisa,

I filled up the form you have on your site under "professional support and commercial Request " , if there is another way to to subscribe Please let me know.

Thank you so much with all this help , really appreciate it.
"

On Tue, Aug 13, 2019 at 3:33 PM Elisa Nectoux <[hidden email]> wrote:
Dear Vivek,

For further assistance, I recommend that you subscribe to our development assistance service.

Best regards,

Elisa Nectoux
Sales & Marketing

+33 (0)9 52 63 65 05
[hidden email]

Belledonne Communications, the company behind the Linphone project




Le 13 août 2019 à 11:58, Vivek Tilva <[hidden email]> a écrit :

Hi Elisa,

Thanks for this info , really appreciate it.

If you can help me with how to set this  DENABLE_RTP_MAP_ALWAYS_IN_SDP = ON from code (from which file i can set this) , would be great.

Thanks in advance

On Tue, Aug 13, 2019 at 2:51 PM Elisa Nectoux <[hidden email]> wrote:
Hi Vivek,

Thank you for your interest in Linphone.

However, it is not correct to say that Linphone is missing the a=rtpmap attributes for pcmu and pcma, as these attributes are not mandatory.

Please refer to RFC3264 [https://tools.ietf.org/html/rfc3264] An Offer/Answer Model Session Description Protocol, in section 5 "Generating the answer":

In the case of RTP streams, all media descriptions SHOULD contain "a=rtpmap" mappings from RTP payload types to encodings.  If there is no "a=rtpmap", the default payload type mapping, as defined by the current profile in use (for example, RFC 1890 [5]) is to be used.

RFC1890 has been replaced by RFC3551 but still defines PCMU and PCMA with static payload type numbers 0 and 8.

Equipments that require rtpmap for static payload types are hence non-conformant with RFC3264.

In order to workaround this non-conformance, linphone has a build-time option to request rtpmap to be always used in SDP. Just pass -DENABLE_RTP_MAP_ALWAYS_IN_SDP=ON to the cmake command line (or prepare.py).

For your information, the reason why we decided many years ago not to honor the "SHOULD" for static payload types is simply to save bytes in the INVITE or 200 Ok length by removing redundant information. Indeed, there are still many use case where MTU limit is major problem, for example when interoperating with SIP gateways that only support SIP/UDP transport.

Best regards,

Elisa Nectoux
Sales & Marketing

+33 (0)9 52 63 65 05
[hidden email]

Belledonne Communications, the company behind the Linphone project




Le 8 août 2019 à 12:21, Vivek Tilva via Linphone-developers <[hidden email]> a écrit :

Hello,

We are facing issue in outgoing calls , calls were not able to go through our provider which we are using , here is reply from our provider , it is related to codec , can you please help us.

Reply from Our provider:

" I checked the samples you have provided and I could observe few things in the calls which have failed.
The main reason for calls failing is because of the mismatch in codec negotiation.
Plivo accepts the call only on PCMU 0 and 8 ( g711).
The calling agent is sending an invite with the codec's 97 98 99 100 0 8 101.
But is missing to send the media attribute description for either 0 or 8, since the codec is not described our servers are rejecting the call.
To fix the issue you will have to send at least one of the codecs in the media attributes only then the calls will be processed"

It there any thing we can change in code to overcome this issue ?

--
Regards,
Vivek Tilva
Application Developer,
US +18572563703 | IN +91 9265391756

_______________________________________________
Linphone-developers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/linphone-developers



_______________________________________________
Linphone-developers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/linphone-developers