[Serdev] Bug in tm module? [possibly]

[Tom Gaudasinski]

Greetings Jan,
    I've been trying things around for a while with the information you 
gave me. I do not understand a few things, I haven't been able to figure 
them out either. You say that in order to generate a BYE both ways, i 
only need to save one dialog? I understand what you mean by splitting 
the route set, but how would I do that? Also, if I only save one 
dialog...won't that only send a BYE to one side of the call and not the 
other? If this is not the case, how am i meant to send two messages to 
both sides of the call from one dialog? does this relate to the 
splitting of the routeset?

Tell me if this rough procedure rundown is right

--INVITE arrives--
new_dlg_uas(dialog)
--200 arrives--
dlg_response_uac(dialog)
#want to send bye's now#
Somehow split the dialog into the uac and uas components and generate 2 
BYEs. how?

Thank you.

Jan Janak wrote:

>On 25-02 16:28, Tom Gaudasinski wrote:
>  
>
>>Greetings,
>>   I'd like your opinion on something I've found. I've been testing my 
>>module for a brief period of time and have come across a questionable 
>>point. I have two types of SIP phones at my disposal, a UOL and a 
>>Grandstream. When generating a packet from a SIP dialog I had saved 
>>earlier using new_dlg_uas, the UOL phone accepts and the Grandstream 
>>rejects. The Grandstream is notably of a much higher quality, however it 
>>fails because the loc_tag(to tag) is not correct in the dialog 
>>structure, whereas it seems the UOL doesn't care about that. After 
>>investigation I have found that I was saving the header on an INVITE, 
>>which does not yet have a loc_tag. So I tried saving my dialog upon an 
>>ACK method, this did not work either although by NGREPing the packets I 
>>had found that the ACK packets indeed DO contain a loc_tag.
>>
>>Saving my dialog and putting some debug code in to watch it shows:
>>
>>0(3641) DEBUG: rem_tag: 0d3b715473d050dd
>>10(3641) DEBUG: loc_tag: b8a22cc221bb15d5ba8e71d646113964-16dd
>>
>>Whereas it 'should' have been:
>>
>>rem_tag: 0d3b715473d050dd
>>loc_tag: as74066c63
>>
>>I trawled through the source to find that the loc_tag is initialised 
>>from a char* called tm_tags, which is declared in t_reply.h. However I 
>>cannot see anything else in the tm module 'set' this tm_tags.
>>
>>Is this indeed a bug? 
>>    
>>
>
>  The tag generator is initialized from the core, see sip_router/tags.h,
>  function init_tags. The reason for this is that the tag generator is
>  used for locally generated stateless replies as well, it is not
>  spefic for tm.
>
>  
>
>>Or if not, why is the loc_tag generated to 
>>something as whacky as the above and how? 
>>    
>>
>
>  Tags generated by ser consist of fixed (MD5 based) part and variable
>  (CRC based part). The fixed part is always the same for subsequent
>  messages, the crc part is unique.
>
>  
>
>>Is there anything I haven't 
>>done that's causing this to happen? Apologies for the length of this post.
>>    
>>
>
>  I think the confusion here comes from the fact that you try to
>  generate a local reply that would have a To tag generated by SER and
>  then, when the callee picks up, you relay the 200 OK response back to
>  the caller, but that response would have a different To tag value.
>
>  There are two ways of tackling this problem:
>
>  1) Fully featured B2BUA Approach
>
>     In this case you would have to treat both sides of the call as
>     separate dialogs (or calls if you want). When the caller sends an
>     INVITE, it will be received by SER and SER would (based on the
>     original INVITE) generate a new INVITE. That new INVITE would be a
>     different call and could possibly have different tags (generated by
>     SER).
>
>     When a 200 OK comes from the callee, SER would received that, it
>     would look up corresponding dialog on the caller's side and
>     generate a new 200 OK, with proper tags for the caller's side of
>     the call. The original (received) INVITE would be dropped and
>     ACKed.
>
>     This is more complex but more generic approach, because you have to
>     keep two dialogs per each call, one for the caller's side and the
>     other one for callee's side.
>
>  2) Man-In-The-Middle Approach
>
>     You could keep just one dialog for the entire call and update it
>     each time you receive a request or response within that dialog.
>     Both sides of the call will be using the same tags and callid.
>     You will get the callid and from tag from the INVITE that
>     establishes the dialog and To tag from 200 OK to that INVITE. That
>     means the dialog structure would be completed after you receive a
>     200 OK.
>
>     Handling Route header fields would be a bit tricky in this case,
>     because you would need to split the route set when you generate a
>     BYE. The cut point would be the Route header field inserted by your
>     proxy.
>
>     Note that you really need to update the dialog structure from every
>     SIP message within that call. The reason is that you need to
>     remember the last values of CSeq in order to be able to generate a
>     BYE.
>
>       Jan.
>
>  
>