[OpenSIPS-Users] t_check_trans and CANCEL

[Lasse Johnsen]

Hi,

I'm having a hard time getting t_check_trans to recognise a particular transaction.

I have a scenario where the client is behind NAT. In this instance, I cannot find a way to properly relay CANCEL.

In my main routing block I have:

 if (is_method("CANCEL")){
                if ( t_check_trans() ) {
                        t_relay();
                }
}

The problem is that my device uses it's internal RFC1918 IP in the Via in the CANCEL.

The invite uses the external IP in the Via.

INVITE: 

Session Initiation Protocol
    Request-Line: INVITE sip:447832335392 at 193.104.93.31 SIP/2.0
        Method: INVITE
        Request-URI: sip:447832335392 at 193.104.93.31
            Request-URI User Part: 447832335392
            Request-URI Host Part: 193.104.93.31
        [Resent Packet: False]
    Message Header
        Max-Forwards: 70
        From: <sip:lasse at 193.104.93.31>;tag=88A1D89809DC70828B238BD874369F6C
            SIP from address: sip:lasse at 193.104.93.31
                SIP from address User Part: lasse
                SIP from address Host Part: 193.104.93.31
            SIP tag: 88A1D89809DC70828B238BD874369F6C
        Contact: <sip:lasse at 87.194.36.133:49477;transport=udp>
            Contact Binding: <sip:lasse at 87.194.36.133:49477;transport=udp>
                URI: <sip:lasse at 87.194.36.133:49477;transport=udp>
                    SIP contact address: sip:lasse at 87.194.36.133:49477
        Allow: ACK
        Allow: CANCEL
        Allow: BYE
        User-Agent: Softphone version 2.6
        To: <sip:447832335392 at 193.104.93.31>
            SIP to address: sip:447832335392 at 193.104.93.31
                SIP to address User Part: 447832335392
                SIP to address Host Part: 193.104.93.31
        Content-Type: application/sdp
        Call-ID: 2803C4C57FC42DD6C26F450AD4F2558016AA63CA
        CSeq: 1 INVITE
            Sequence Number: 1
            Method: INVITE
        Via: SIP/2.0/UDP 87.194.36.133:49477;branch=z9hG4bK2;rport
            Transport: UDP
            Sent-by Address: 87.194.36.133
            Sent-by port: 49477
            Branch: z9hG4bK2
            RPort: rport
        Content-Length: 182

The cancel has an internal RFC1918 IP address:

CANCEL:

Session Initiation Protocol
    Request-Line: CANCEL sip:447832335392 at 193.104.93.31 SIP/2.0
        Method: CANCEL
        Request-URI: sip:447832335392 at 193.104.93.31
            Request-URI User Part: 447832335392
            Request-URI Host Part: 193.104.93.31
        [Resent Packet: False]
    Message Header
        Call-ID: 2803C4C57FC42DD6C26F450AD4F2558016AA63CA
        To: <sip:447832335392 at 193.104.93.31>
            SIP to address: sip:447832335392 at 193.104.93.31
                SIP to address User Part: 447832335392
                SIP to address Host Part: 193.104.93.31
        From: <sip:lasse at 193.104.93.31>;tag=88A1D89809DC70828B238BD874369F6C
            SIP from address: sip:lasse at 193.104.93.31
                SIP from address User Part: lasse
                SIP from address Host Part: 193.104.93.31
            SIP tag: 88A1D89809DC70828B238BD874369F6C
        CSeq: 1 CANCEL
            Sequence Number: 1
            Method: CANCEL
        Via: SIP/2.0/UDP 192.168.0.200:49477;branch=z9hG4bK2;rport
            Transport: UDP
            Sent-by Address: 192.168.0.200
            Sent-by port: 49477
            Branch: z9hG4bK2
            RPort: rport
        Max-Forwards: 70
        Content-Length: 0


I have also tried the following:

 if (is_method("CANCEL")){
                force_rport();
                add_rcv_param();
                fix_nated_contact();
                if ( t_check_trans() ) {
                        t_relay();
                }
}

This doesn't make a difference.

The RFC3261branch in both INVITE and CANCEL magic cookie is identical (z9hG4bK2).

in modules/tm/t_lookup.c we have:

static inline int via_matching( struct via_body *inv_via,
                                struct via_body *ack_via )
......
if (memcmp(inv_via->host.s, ack_via->host.s,
                        ack_via->host.len)!=0)
return 0;

When our CANCEL passes then: 

ack_via->host.s is 192.168.0.200
inv_via->host.s is 87.194.36.133

Therefore there is no match. 

In the instance where we remove this host check the CANCEL is processed correctly.

How can this be resolved more reasonably?


Sincerely,


Lasse