I have a SIP Server which is registering to a trunk. So, SIP Server sends a REGISTER message to the trunk. But the trunk device sends a "406 Not Acceptable" error message. I have been told that this error is because there is no user part in 'Contact' header. However, as per RFC, Contact header on its own is not mandatory to be in a REGISTER request.
Could you please help to confirm if my understanding is right and advise accordingly?
REGISTER sip:10.5.5.1 SIP/2.0
From: sip:70999#10.5.5.1;tag=8CD78147-5BDB-40C1-87F6-64A6905F1A6D-9
To: <sip:70999#10.5.5.1>
Call-ID: FCC64207-4F2A-4622-AF85-B77BBE3C7796-9#10.5.5.2
CSeq: 1 REGISTER
Content-Length: 0
Via: SIP/2.0/UDP 10.5.5.2:5060;branch=z9hG4bKA761AE66-C376-4895-BBF7-51CF2C675C52-9
**Contact: <sip:10.5.5.2:5060>**
Expires: 600
SIP/2.0 406 Not Acceptable
Via: SIP/2.0/UDP 10.5.5.2:5060;branch=z9hG4bKA761AE66-C376-4895-BBF7-51CF2C675C52-9
From: <sip:70999#10.5.5.1>;tag=8CD78147-5BDB-40C1-87F6-64A6905F1A6D-9
To: <sip:70999#10.5.5.1>;tag=10a8faa5
Call-ID: FCC64207-4F2A-4622-AF85-B77BBE3C7796-9#10.5.5.2
CSeq: 1 REGISTER
User-Agent: XXX XXX XXX
Allow: INVITE, ACK, REGISTER, BYE, OPTIONS, INFO, CANCEL, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE
Content-Length: 0
10.5.5.2 is my SIP Server and 10.5.5.1 is the Trunk device
Thank you.
You are correct. For all address of records, including any in a Contact header, the user portion is optional.
For REGISTER requests in particular see 10.2.1 Adding Bindings which states:
The Contact header field values of the request typically consist of
SIP or SIPS URIs that identify particular SIP endpoints (for example,
"sip:carol#cube2214a.chicago.com"), but they MAY use any URI scheme.
A SIP UA can choose to register telephone numbers (with the tel URL,
RFC 2806 [9]) or email addresses (with a mailto URL, RFC 2368 [32])
as Contacts for an address-of-record, for example.
For the case where the Contact header contains a SIP URI the rules are specified as shown below. The [userinfo] portion which contains the "user part" you're referring to is optional.
SIP-URI = "sip:" [ userinfo ] hostport
uri-parameters [ headers ]
SIPS-URI = "sips:" [ userinfo ] hostport
uri-parameters [ headers ]
userinfo = ( user / telephone-subscriber ) [ ":" password ] "#"
Despite the fact that you are correct most SIP servers do implement additional business rules. Some Registrars don't accept request with a private IP address in the Contact URI etc.
Related
I am getting the below Error messages in syslog. Can anyone tell me why these two methods getting failed. Is there anything I am missing to configure in SIP phone.
ERROR: {1 2 REGISTER 619499693} [core/parser/parse_methods.c:456]: parse_methods(): Invalid method
ERROR: {1 2 REGISTER 619499693} [core/parser/parse_allow.c:65]: parse_allow_header(): bad allow body header
The captured register message below:
REGISTER sip:77.10.86.8;user=phone SIP/2.0
Via: SIP/2.0/UDP 77.10.86.9:5060;rport;branch=z9hG4bK1290987256
From: "USER1" sip:90000001#77.10.86.8;user=phone;tag=822848271
To: "USER1" sip:90000001#77.10.86.8;user=phone
Call-ID: 619499693
CSeq: 1 REGISTER
Contact: "USER1" sip:90000001#77.10.86.9:5060
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, UPDATE, INFO, SUBSCRIBER, NOTIFY, MESSAGE, PRACK, REFER
Max-Forwards: 70
User-Agent: eXosip/3.6.0
Expires: 3600
Supported: eventlist, replaces, tdialog, timer, 100rel
Allow-Events: dialog, message-summary, refer, reg, ua-profile
Content-Length: 0
The from and to headers do not comply with rfc3261 syntax:
From: "USER1" sip:90000001#77.10.86.8;user=phone;tag=822848271
To: "USER1" sip:90000001#77.10.86.8;user=phone
When a display name is used, the URI needs to be enclosed between <>
From: "USER1" <sip:90000001#77.10.86.8;user=phone>;tag=822848271
To: "USER1" <sip:90000001#77.10.86.8;user=phone>
You will find more details in rfc3261.
EDIT:
I was too fast in answering. The error mention a wrong value in Allow header. SUBSCRIBER (typo for SUBSCRIBE) is not defined by any specification. However, in rfc3261, such values (unknown) are allowed by the specification, and such header is correct from a syntax perspective.
Here is an example of how I have configured sieve to forward any mail sent to [nameA|nameB|nameC]#example.org to my private email address.
if address :localpart :is ["To","Cc","Bcc"]
["nameA", "nameB", "nameC"] {
redirect "<my private email address>";
stop;
}
Sometimes though, email is not forwarded because the address that it was sent to is tucked away somewhere in a "Received" header.
Received: from ###server### ([###ip_address###])
by ###server### with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256)
(Exim 4.84)
(envelope-from <###email_address###>)
id 1alDM0-0000yT-60
for nameA#example.org; Wed, 30 Mar 2016 12:28:00 +0200
Is there an effective way to catch these emails in the sieve rule, too?
You have an XY Problem here. What you actually want to do here is filter based on the address being delivered to, not the address in the headers. (As unintuitive as it may be, the address in the headers may have nothing to do with the address it's being delivered to, which is how Bcc can work at all.)
The command to test against the actual SMTP envelope is envelope.
require "envelope";
if envelope :localpart :is "to" ["nameA", "nameB", "nameC"] {
redirect "<my private email address>";
stop;
}
This will handle all mail being delivered to those names, regardless of whether they show up in the mail headers or not.
With the help of the sieves' index feature you can parse the recipient address out of the Received headers.
For BCC sorting I typically do something like this:
require ["fileinto", "envelope", "variables", "mailbox", "index", "subaddress"];
...
if header :index 3 :matches "Received" "*<*#example.com>*" {
set :lower "foldername" "${2}";
fileinto :create "inbox.${foldername}";
} elsif header :index 2 :matches "Received" "*<*#example.com>*" {
set :lower "foldername" "${2}";
fileinto :create "inbox.${foldername}";
}
...
In the Received headers of the mails I receive the adress is set in angle brackets and that's why I've chosen the pattern in the example above.
Additionally, sometimes the number of Received headers varies thus I test at least for two different ones.
a typical sip packet looks like this
INVITE sip:bob#biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob#biloxi.com>
From: Alice <sip:alice#atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710#pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice#pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
so is it possible to embedd perl or tcl parser in c
I would use a packet sniffer in C. Then identify SIP protocol based on data, push it somewhere and parse it with Perl/TCL from there. Example:
http://www.tcpdump.org/sniffex.c, or you can build packet sniffer from Perl/TCL itself, very easy task just some considerations when handling TCP/UDP fragmentation
I have a strange problem where pjsip ignores the record route info while sending the ack. Below are the sip message flow from the logs:
INVITE sip:+110#xxx.com;transport=tls SIP/2.0
Via: SIP/2.0/TLS ipv4.addr:38890;rport;branch=z9hG4bKPjdYP6TZrj4w7v8kicC3cBgABBNb47QHH2;alias
Max-Forwards: 70
From: "+558" <sip:+558#xxx.com>;tag=qfc3TEYcpfIBQHVXMOmh.7pyvqgmVdMh
To: sip:+110#xxx.com
Contact: "+558" <sip:+558#xxx.com>
Call-ID: 7FdLGhQ1L5BjAQsUrCPEOB3WbXipRfs1
CSeq: 18162 INVITE
Route: <sip:xxx.com:5061;transport=tls;lr>
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
User-Agent: SecuVOICE BB10 CSE 2.14.0.1 on Z10 10.3.1.2243
Authorization: Digest xxxx
Content-Type: application/x-x509-user-cert
Content-Length:
SIP/2.0 200 OK
Max-Forwards: 10
Via: SIP/2.0/TLS ipv4.addr:38890;rport=38890;received=ipv4.addr;branch=z9hG4bKPjdYP6TZrj4w7v8kicC3cBgABBNb47QHH2;alias
Record-Route:<sip:xxx.com:5061;transport=tls;lr;ftag=qfc3TEYcpfIBQHVXMOmh.7pyvqgmVdMh;cookie_=e43.052768f7>
Call-ID: 7FdLGhQ1L5BjAQsUrCPEOB3WbXipRfs1
From: "+558" <sip:+558#xxx.com>;tag=qfc3TEYcpfIBQHVXMOmh.7pyvqgmVdMh
To: <sip:+110#xxx.com>;tag=RuDb.RX-9YD0V.BKh0rpj61-SK-ORE5B
CSeq: 18162 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Contact: "+110" <sip:+110#ipv4.addr:25365>
Supported: replaces, 100rel, timer, norefersub
Content-Type: multipart/mixed;boundary=SBC1hJLGTAfp3t2j3HYWIvvgUBsC1RpJ
Content-Length: 27
ACK sip:+110#ipv4.addr:25365 SIP/2.0
"+110" <sip:+110#ipv4.addr:25365>
Via: SIP/2.0/TLS ipv4.addr:38890;rport;branch=z9hG4bKPjkp-dUZmmgpXNWrZHe2ykqvrr9CgRvlm2;alias
Max-Forwards: 70
From: "+558" <sip:+558#xxx.com>;tag=qfc3TEYcpfIBQHVXMOmh.7pyvqgmVdMh
To: sip:+110#xxx.com;tag=RuDb.RX-9YD0V.BKh0rpj61-SK-ORE5B
Call-ID: 7FdLGhQ1L5BjAQsUrCPEOB3WbXipRfs1
CSeq: 18162 ACK
Route: <sip:xxx.com:5061;transport=tls;lr;ftag=qfc3TEYcpfIBQHVXMOmh.7pyvqgmVdMh;cookie_=e43.052768f7>
Content-Type: application/sdp
Content-Length: 709
Looking at the record route from 200 OK, I expected the ACK to look like
ACK sip:+110#ipv4.addr:25365;transport=tls;lr SIP/2.0
Why pjsip is ignoring the transport uri parameter?
Received Record-Route are copied as Route in a new outgoing request within the dialog.
The exception is if the Record-Route URI does not carry a ";lr" parameter. This is the backward compatible behaviour with RFC 2543
The Request URI of the outgoing request is set to the received Contact header.
See RFC 3261 Section 12.2.1.1
The UAC uses the remote target and route set to build the
Request-URI and Route header field of the request.
If the route set is empty, the UAC MUST place the remote target URI
into the Request-URI. The UAC MUST NOT add a Route header field to
the request.
If the route set is not empty, and the first URI in the route set
contains the lr parameter (see Section 19.1.1), the UAC MUST place
the remote target URI into the Request-URI and MUST include a Route
header field containing the route set values in order, including all
parameters.
If the route set is not empty, and its first URI does not contain
the lr parameter, the UAC MUST place the first URI from the route
set into the Request-URI, stripping any parameters that are not
allowed in a Request-URI. The UAC MUST add a Route header field
containing the remainder of the route set values in order,
including all parameters. The UAC MUST then place the remote
target URI into the Route header field as the last value.
The route set is either pre-configured, or learned through the Record-Route.
Target URI is updated when receiving a Contact header from the other party.
When sending an email, the recipient list is given during the SMTP dialogue through RCTP TO: command. Later, in DATA command, header fields like 'To', 'Cc','bcc' are indicated. Does this RCPT TO list of recipients have to match with the headers indicated in DATA command?
Also, if the recipient is not indicated in RCPT TO, but in the To field of email header, is it going to be delivered to the recipient not in RCPT TO?
No, they don't have to match. When the message is sent, the SMTP Server (aka Message Transfer Agent or MTA) is creating a so called SMTP envelope which contains the recipients and the sender of the message (see RFC5321):
SMTP transports a mail object. A mail object contains an envelope and content. The SMTP envelope is sent as a series of SMTP protocol
units (described in Section 3). It consists of an originator
address (to which error reports should be directed), one or more
recipient addresses, and optional protocol extension material.
It is, actually, quite often that the RCPT TO: Command has more recipients that the header of the message - one common case is the usage of "blind copies" bcc: (see RFC5321):
Addresses that do not appear in the message header section may appear
in the RCPT commands to an SMTP server for a number of reasons. The
two most common involve the use of a mailing address as a "list
exploder" (a single address that resolves into multiple addresses) and
the appearance of "blind copies".
Does this RCPT TO list of recipients have to match with the headers
indicated in DATA command?
Nope.
if the recipient is not indicated in RCPT TO, but in the To field of
email header, is it going to be delivered to the recipient not in RCPT
TO ?
The RCPT. Here's a (modified) transcript from my own SMTP client where I do just what you ask:
CLIENT: MAIL FROM:<myaccount#gmail.com>
SERVER: 250 2.1.0 OK
CLIENT: RCPT TO:<myaccount#gmail.com>
SERVER: 250 2.1.5 OK
CLIENT: DATA
SERVER: 354 Go ahead
CLIENT: Subject: Test email
CLIENT: From:'John Doe'<fakeaccount#gmail.com>
CLIENT: To:'John Doe'<fakeaccount#gmail.com>
CLIENT: This is a test...
CLIENT: .
The message was successfully sent to "myaccount#gmail.com".
SMTP protocol (RFC 2821) states the following:
When RFC 822 format [7, 32] is being used, the mail data include the
memo header items such as Date, Subject, To, Cc, From. Server SMTP
systems SHOULD NOT reject messages based on perceived defects in the
RFC 822 or MIME [12] message header or message body.
And this:
The DATA command can fail at only two points in the protocol
exchange:
If there was no MAIL, or no RCPT, command, or all such commands
were rejected, the server MAY return a "command out of sequence"
(503) or "no valid recipients" (554) reply in response to the DATA
command. If one of those replies (or any other 5yz reply) is
received, the client MUST NOT send the message data; more
generally, message data MUST NOT be sent unless a 354 reply is
received.
From these statements, the headers and RCPT TO: command content does not have to match (altough they should match), and not using RCPT TO: MAY result in an error to prevent proceeding with DATA command.