Sending Custom SIP INFO Packet During a Call

Development
1

Hi guys,

similar to AOC and DTMF INFO we built a patch for sending a customized SIP INFO with specific informations available on channels such as source and dest numbers and ip, etc during a call to the trunk provider and internal calls both in SIP and WebRTC. (SIP INFO is implemented in SRCCHANGE indicator and we use Chan_PJSIP driver)

When the SIP INFO packet is sent, it causes the call to drop after 32 seconds. [Picture attached]

Screenshot 2023-03-05
Screenshot 2023-03-052856×1824 439 KB

What could be the main reason and how can we address this issue?
What is the best way to implement a SIP INFO during a call?

Thanks

2

The other party is violating the protocol by not sending a final response:

https://www.rfc-editor.org/rfc/rfc2976#page-4

Sorry. There is a message body, so you need to tell us the RFC that defines how the request should be handled, as RFC 2976 excludes itself from such cases. However it is likely that any such RFC would require at least a provisional response within 32 seconds, and it is also likely that Asterisk does not know about that RFC.

3

This is the reference given by the provider for SIP INFO Method for body and sending.

Here is an example if what we need to send:

INFO sip:alice@pc33.example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef To: Bob <sip:bob@example.com>;tag=a6c85cf
From: Alice <sip:alice@example.com>;tag=1928301774 Call-Id: a84b4c76e66710@pc33.example.com
CSeq: 314333 INFO
Info-Package: extraservice
Content-type: application/exserv
Content-Disposition: Info-Package
Content-length: 103
service=ivr;action=2;cid=12345678;cidname=12345678;dest=87654321;aip=89.235.69.25 4:5060;bip=31.3.4.7
4

I missed that there had been an update, however that update removes the uncertainty about a response. Section 4.2.2 makes it clear that a final response is mandatory. (Incidentally, several sites host RFCs. Only the RFC number is relevant in distinguishing between them.)

Looking a bit further, section 7.1 says that an Info-Package header is mandatory, except for legacy uses. My guess is that the code is only written to handle legacy uses, which is why it is missing from your request. It would seem to me that the spirit of the first paragraph of 4.2.2 is that they should have replied with a 469 error response.

It is confusing as to whether Content-Disposition is mandatory. The correct form of words isn’t used to achieve that, but, on the other hand the wording does suggest that body parts won’t be recognized without it. The reference to original RFC isn’t useful, as it is always optional there unless you provide a session description which doesn’t have the SDP Content-Type.

Also, regarding Info Packages, this RFC only provides a framework. A proper specification requires a document for the info package as well.

Also note that their example is malformed. There should not be a blank line before the CSeq line and there should be a blank line between 103 and service. There should be a To line, as you need both From and To to provide the tags needed to completely identify the session.

5

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.